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

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

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

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

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

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

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

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

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

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

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

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

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

У меня эта ошибка возникала раньше, даже в 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"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

taskkill /f /im vstest.*
exit 0

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

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

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

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

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

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

VS 2013; Победа 8;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Помогал

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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