Ошибка: невозможно получить доступ к файлу bin / Debug /… потому что он используется другим процессом


113

Когда я отлаживаю свой проект, я получаю следующую ошибку:

"Невозможно скопировать файл" obj \ Debug \ My Dream.exe "в" bin \ Debug \ My Dream.exe ". Процесс не может получить доступ к файлу bin \ Debug \ My Dream.exe, потому что он используется другим обработать."

Используя Process Explorer, я вижу, что MyApplication.exe отсутствует, но системный процесс по-прежнему использует его, хотя раньше я прекращал отладку. Когда я изменяю свой код и начинаю отладку, это произойдет. Если я копирую проект на USB и отлаживаю, он работает нормально.

Зачем? Как исправить эту ошибку?

Я использую Window 7 Professional. С Xp у меня никогда не было этой ошибки.


1
Win7 иногда блокирует файлы, которые просматриваются в проводнике, поэтому убедитесь, что у вас не открыта папка отладки.
Necrolis

Я думаю, что Системный процесс его использует.
Trần Minh

1
Это либо блокировка, либо какой-то идиот добавил / bin в систему управления версиями, и теперь файлы защищены от записи (щелкните правой кнопкой мыши на bin, снимите флажок с защитой от записи).
Stefan Steiger

3
В Visual Studio 2017 это хуже, чем когда-либо прежде.
Роб Линдон

1
В моем случае MSBuild.exeфайл был
Пьер

Ответы:


120

Ух, это старая проблема, которая время от времени всплывает в Visual Studio. Он укусил меня пару раз, и я потерял несколько часов на перезапуск и борьбу с VS. Я уверен, что это обсуждалось здесь, на SO, не раз. Об этом также говорили на форумах MSDN. Реального решения нет, но есть несколько обходных путей. Начните исследование здесь .

Что происходит, так это то, что VS получает блокировку файла, а затем не снимает ее. По иронии судьбы, эта блокировка не позволяет самой VS удалить файл, чтобы он мог воссоздать его при пересборке приложения. Единственное очевидное решение - закрыть и перезапустить VS, чтобы он снял блокировку с файла.

Моим первоначальным обходным решением было открытие папки bin / Debug и переименование исполняемого файла. Если он заблокирован, удалить его нельзя , но можно переименовать. Таким образом, вы можете просто добавить число в конец или что-то в этом роде, что позволит вам продолжить работу, не закрывая все окна и не дожидаясь перезапуска VS. Некоторые люди даже автоматизировали это, используя событие перед сборкой, чтобы добавить случайную строку в конец старого выходного имени файла. Да, это гигантский взлом, но эта проблема становится настолько разочаровывающей и изнурительной, что вы будете делать что угодно.

Позже, после небольшого количества экспериментов, я узнал, что проблема, кажется, возникает только тогда, когда вы создаете проект с открытым одним из дизайнеров. Итак, решение, которое работало для меня долгое время и не позволяло мне когда-либо снова столкнуться с одной из этих глупых ошибок, - это убедиться, что я всегда закрываю все окна дизайнера перед созданием проекта WinForms. Да, это тоже несколько неудобно, но наверняка избавит от необходимости перезапускать VS два раза в час или больше.

Я предполагаю, что это относится и к WPF, хотя я не использую его и лично не сталкивался с этой проблемой.

Я также еще не пробовал воспроизвести его на VS 2012 RC. Не знаю, исправили это там или нет. Но по моему опыту, он все еще появляется, даже после того, как Microsoft заявила, что исправила его. Он все еще присутствует в VS 2010 SP1. Я, конечно, не говорю, что их программисты идиоты, которые не знают, что делают. Я полагаю, что существует несколько причин ошибки и / или ее очень трудно надежно воспроизвести в лаборатории. По той же причине, по которой я лично не отправлял никаких отчетов об ошибках (хотя я поставил +1 другим людям), потому что я не могу надежно воспроизвести его, как "Мерзкого снеговика".

<конец разглагольствования, направленного ни на кого конкретно>


1
Это все еще происходит (для меня) в VS2013. В моем решении всегда блокируется файл PDB для проекта WPF в моем решении в целевом каталоге. Закрытие всех дизайнеров не сработало (ух!), Но переименование файла сработало (спасибо, Коди!). Гигантский хак манит ...
Джон

2
Это начало происходить со мной со вчерашнего дня, когда я обновился до vS 2013 ... со мной такого не случалось ни разу с VS 2008 ... так грустно.
SomeNickName

8
VS 2015, и у меня все еще есть проблема.
Берин Лорич

13
Это происходит в Visual Studio 17, и перезапуск Visual Studio не помогает.
Роб Линдон

2
@jairhumberto нет причин для шуток, компьютеры и так достаточно расстраивают, не нужно передавать это кому-то другому ... но это работает для меня для этой конкретной проблемы, возможно, у вас что-то другое! См .: stackoverflow.com/a/19649014/27494
ScottN

64

У меня эта ошибка возникала раньше, даже в Visual Studio 2008. Она вернулась и стала более распространенной в Visual Studio 2012.

Вот что я делаю.

Вставьте это в событие предварительной сборки проблемного проекта:

if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

1
Где я могу найти это Pre-Buildсобытие в моей форме Windows?
Unknownymous 08

2
@qwerty Он находится в свойствах проекта в разделе "События сборки" или, если вы работаете в проекте VB.net, в разделе "Компиляция" вы увидите кнопку "События сборки".
ScottN

@ScottN: о, кстати, этот pre-buildкод также является средством для развернутого (через щелчок один раз) приложения, когда мое приложение запущено, затем в диспетчере задач произошла ошибка / сбой, я завершу задачу, myApp.exeно не завершу задачу, и она предложит ERROR ON ENDING TASK?
Unknownymous

@qwerty Нет, это не связано с развернутым приложением ClickOnce. Эта ошибка возникает только тогда, когда вы создаете свое приложение во время разработки и тестирования, и только в Visual Studio, а не для любого развернутого приложения, работающего в клиентских системах.
ScottN

К чему .lockedотносится?
Шимми Вайцхандлер

22

Компьютер (щелкните правой кнопкой мыши) -> управлять -> Служба и приложение -> служба -> Включить взаимодействие с приложением

Сработало для меня!


2
Я отключил эту службу несколько месяцев назад. Включение этого теперь, похоже, решило проблему в Visual Studio (невозможно скопировать из-за блокировки exe-файла). Интересно, почему эта служба должна быть запущена? То, что я читал о ней, похоже, не связано ни с чем, имеющим отношение к этой ошибке (например, blackviper.com/windows-services/application-experience ).
Андреас Янссон

10
У меня работает эта служба, но проблема с блокировкой все еще возникает.
antfx

1
+1 Вау, попробовал / все / еще нашел. Наконец то наткнулся на это, чтобы исправить. Моя тоже была выведена из строя. Никогда бы не подумал, что виноват!
Джон С.

Запуск Windows 7 с пакетом обновления 1 (SP1) с VS2010 с пакетом обновления 1 (SP1), включение служб «Application Experience» сразу же мне помогли. Большое спасибо. Но выключение через минуту не приводит к немедленному воспроизведению проблемы.
Джимм Чен

7
сервис не найден в Windows 10
JerryGoyal

13

У меня была такая же проблема в Visual Studio 2013. Я не уверен, что вызвало ее в моем проекте, но я смог исправить ее, очистив решение и перестроив его.

  1. Сборка> Чистое решение
  2. Сборка> Восстановить решение

1
Не пробуйте его на больших проектах ... Полная перестройка занимает очень много времени.
mBardos 05

7

По крайней мере, в моем случае я заметил, что Visual Studio 2012 создала как минимум два призрачных процесса msbuild.exe, которые не исчезли после сборки. Эти зомби, по-видимому, вызывают блокировку файлов.

Удаление msbuild.exe - это одноразовое решение, это нужно делать для каждой сборки.

Но потом я понял, что могу отключить параллельную сборку раз и навсегда - зашел в Инструменты> Параметры> Проекты и решения> Сборка и запуск> «максимальное количество параллельных сборок проекта» - по умолчанию он имеет значение 8, я Перешел на 1. Брелок работает.

Конечно, сборки сейчас немного медленнее, но лучше перестраховаться. По крайней мере, для этого небольшого проекта мне не требовалось более одного потока сборки.


7

Я так понимаю, это старый вопрос. К сожалению, я столкнулся с той же проблемой с моим .net core 2.0приложением в visual studio 2017. Итак, я подумал о том, чтобы поделиться решением, которое сработало для меня. Перед этим решением я пробовал следующие шаги.

  1. Перезапущенная визуальная студия
  2. Закрыл все приложение
  3. Очистите мое решение и восстановите

Ни один из вышеперечисленных шагов не устранил проблему.

Затем я открыл свой Task Managerвыбранный dotnetпроцесс и нажал кнопку «Завершить задачу». Позже я открыл свою Visual Studio, и все работало нормально.

введите описание изображения здесь


2

См. Мой ответ здесь, если у вас возникла эта проблема при запуске модульных тестов. Ответ скопирован ниже:

Основываясь на ответе Себастьяна, я добавил в свой тестовый проект этап предварительной сборки, чтобы автоматически убить все vstest.*еще работающие исполняемые файлы. У меня сработала следующая команда предварительной сборки:

taskkill /f /im vstest.*
exit 0

Команда exit 0находится в конце, чтобы предотвратить сбой сборки, когда vstest.*исполняемые файлы не запущены.


1

Недавно у меня возникла проблема с Visual Studio 2012 с таким же описанием ошибки: «Процесс не может получить доступ к файлу, потому что он используется другим процессом ...»

Чтобы исправить это, прежде всего, вам нужно понять приложение, которое все еще его использует. Я отключил все процессы, такие как «MSBuild» и «MSBuild host». Но этого недостаточно. Если вы установили и включили «Контракты кода», иногда требуется, чтобы ваши DLL проверяли и зависали при этой операции.

Итак, вам нужно остановить все процессы «CCCheck.exe» и все.

Наконец, чтобы понять, что процесс использует вашу DLL, вы всегда можете попробовать просто удалить папку «obj» в вашем файловом менеджере, и эта операция завершится ошибкой, вы можете увидеть «Окно сообщений» с описанием зависшей операции. Также, как вариант, вы можете попробовать использовать приложение «Sys Internals Suite».


По крайней мере, в моем случае я заметил, что визуальная студия создавала процессы-призраки msbuild.exe, которые не исчезли после сборки. Эти зомби, по-видимому, вызывают блокировку файлов. Но понятия не имею, как это решить. Удаление msbuild.exe - это одноразовое решение, это нужно делать для каждой сборки.
TarmoPikaro

1

Работал у меня. Диспетчер задач -> Название проекта -> Завершить задачу. (у меня было 3 одинаковых процесса с моим названием проекта);

VS 2013; Победа 8;


1

Убедитесь, что любой предыдущий запуск приложения (например, запуск без опции отладки) фактически остановлен. Я работал над приложением WPF, запустил без отладки и свернул его, когда продолжал получать ошибку. После закрытия приложения поведение VS вернулось в норму.


1

Меня мучила эта проблема в Visual Studio 2017. Она началась около двух или трех недель назад и сильно сказалась на моей производительности. Clean и Rebulid не работали; даже перезапуск моей машины не помогает.

Один из способов решения этой проблемы - очистить сборку, которая нарушила работу, и сразу же после этого построить (а не перестраивать) проект, который вы хотите запустить. Это работает примерно в 30% случаев.

Однако, вероятно, самое надежное решение, которое я нашел, - это открыть командную строку разработчика и использовать ее msbuildнапрямую. Я занимаюсь этим последние три дня, и пока проблема ни разу не возникла.


1

В моем случае было то, что я включил «Показать все файлы». Visual Studio 2017


1

Беги taskmanager.
Найдите netcoreи удалите его.
Затем вы можете удалить файл вручную или запустив Clean.


0

Это чистое предположение, а не ответ.

Однако у меня была эта проблема некоторое время.

Я пришел через некоторое время, чтобы заподозрить взаимодействие между VS и моими мерами предосторожности AV.

После некоторой игры кажется, что он мог исчезнуть, когда я изменил свой антивирус так, чтобы все, что под

C: \ Users [имя пользователя] \ AppData \ Local \ Microsoft \ VisualStudio \ 10.0 \ ProjectAssemblies

папка не была включена в постоянную защиту.

Похоже, что сборка сначала записывает здесь DLL, а затем копирует ее в место окончательной сборки.


0

Может быть уже слишком поздно. Но я столкнулся с аналогичной проблемой, и в моем случае у проекта была ссылка на себя. Следовательно, удаление его из ссылок сработало как шарм !!!


0

Я нашел самый быстрый способ без закрытия форм и перезапуска VisualStudio - это перейти на страницу компиляции проекта и нажать кнопку «Дополнительные параметры компиляции ...». Затем внесите какие-либо изменения в один из параметров (например, измените «Создать отладочную информацию» с «Полная» на «Только pdb»), затем нажмите «ОК». Он работает каждый раз, и его придется делать, пока MS не исправит эту ошибку (у меня никогда не было этой проблемы, пока я не переключился с VS2012 на VS2013)

Еще одно замечание: если вы не можете очистить проект или решение, оно не будет построено. Файлы определенно заблокированы VS (не проблема с антивирусом, по крайней мере, в моем случае)


0

Я попробовал все эти предложения, а также другие предложения, найденные в другом месте, и единственное, что у меня сработало, - это перезагрузка компьютера. Затем я сделал чистое решение с последующим восстановлением. Я использую Visual Studio 2013 для справки.


0

Я столкнулся с этой же проблемой и обнаружил, что в фоновом режиме работает несколько приложений Windows Forms . Это происходит, когда ваше приложение имеет две формы, и вы закрываете вторую форму, которая не является вашей основной формой, поэтому приложение не будет полностью закрыто.

Я обычно запускаю свое приложение

  • через его exe или
  • запустить без отладки

Решение - закрыть другой экземпляр приложения Windows Form . Это один из способов всегда закрывать экземпляр вашего приложения.


0

Команда предварительной сборки

(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb)

Помогал


0

[Решено] Ошибка: не удается получить доступ к файлу bin / Debug /…, потому что он используется другим процессом:

Я приближаюсь к тому, что вы получаете эту ошибку, когда пытались запустить два окна формы одно за другим, например, сначала загружая форму, а затем иногда она автоматически исчезает, а вторая форма загружается на экран.

По сути, вам нужно закрыть свою первую форму, которая работает в фоновом режиме, и указать основную причину этой ошибки.

Чтобы закрыть первую форму, вам нужно добавить эти две строки кода в обработчик события загрузки второй формы.

    Form1 form = new Form1();
    form.Close();

Это отлично решит ошибку.


0

Одно простое решение - перейти в папку bin \ Debug, удалить все файлы в этой папке, а затем перестроить. Если это не сработает, закройте Visual Studio, затем перейдите в папку bin \ Debug с помощью проводника файлов, в левой части окна щелкните Файл> Открыть командную строку> Открыть командную строку от имени администратора> Введите эту команду «DEL / F / Q / A * "> затем перестройте


0

Я нашел ответ Коди Грея частично полезным, поскольку он направил меня к реальному источнику моей проблемы, с которой некоторые из вас также могут столкнуться: выполнение теста Visual Studio остается открытым по умолчанию и поддерживает блокировку файлов.

Чтобы остановить это преимущественно бесполезное поведение, следуйте инструкциям из https://connect.microsoft.com/VisualStudio/feedback/details/771994/vstest-executionengine-x86-exe-32-bit-not-closing-vs2012-11-0 -50727-1-ртмрел

Снимите флажок "Тестовое меню" -> "Настройки теста" -> "Продолжать работу механизма выполнения тестов".


0

Моя проблема заключалась в том, что dotnet зависал, и всякий раз, когда VS пытался создать новую dll или получить доступ к старой, процесс dotnet фиксировался на dll и не позволял Visual Studio клонировать dll. Решение состоит в том, чтобы просто завершить все задачи dotnet в диспетчере задач (он фактически удалит только мертвый, если вы пытаетесь завершить его, и он не закрывается, это означает, что он работает).


0

Закройте VisualStudio, ctrl-alt-delete, выберите диспетчер задач, найдите и завершите все процессы MSBuild - VisualStudio в основном имеет довольно серьезную ошибку, при которой он теряет контроль над своим отладчиком, а отладчик поддерживает блокировку файла .pdb в отладке / bin папка. После завершения всех процессов MSBuild (отладчика) удалите папку / debug / bin и снова откройте свое решение в Visual Studio. Теперь тебе хорошо идти. Microsoft нужно исправить эту хрень.


0

Я открыл отдельный вопрос относительно VS 2017, у которого было аналогичное поведение после одного обновления. Проблема, похоже, была вызвана антивирусной программой.

Я добавил папку bin в список исключений антивируса, перезапустил машину, и теперь, похоже, она работает.


0

Я решил эту проблему ..

рядом с отладкой вы видите выпадающее меню с некоторой конфигурацией. По умолчанию был Any CPU. Выберите x86 и запустите программу, она будет работать. Если x86 нет, перейдите в диспетчер конфигурации и добавьте x86


-1

Еще один кладж, тьфу, но он прост и работает у меня в VS 2013. Щелкните проект. На панели свойств должна быть запись с именем Project File со значением

(название вашего проекта) .vbproj

Измените имя проекта - например, добавьте -01 в конец. Исходный файл .zip, который был заблокирован, все еще существует, но больше не упоминается ... так что ваша работа может продолжаться. При следующей перезагрузке компьютера эта блокировка исчезнет, ​​и вы сможете удалить ошибочный файл.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.