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

У меня есть C # webforms приложение , которое до сегодняшнего дня работало нормально.

Сегодня, внезапно, каждый раз, когда я пытаюсь запустить приложение, я получаю ошибку блокировки файла:

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

Поиск в Google ошибки не дает ничего, кроме очевидного, то есть VS думает, что файл заблокирован. И определенно сама Visual Studio блокирует файл, потому что, когда я закрываю VS и снова открываю его, проект выполняется нормально - с первого раза. Когда я пытаюсь запустить его второй раз, я получаю сообщение об ошибке блокировки файла.

Закрытие VS и повторное открытие каждый раз, когда я хочу запустить приложение, не является жизнеспособным решением! Как мне узнать, что блокирует файл, и предотвратить его блокировку?

РЕДАКТИРОВАТЬ: Еще одно интересное открытие: мне даже не нужно запускать приложение. Простая его компиляция вызывает блокировку файла; Не могу скомпилировать дважды подряд!

Эта проблема относится к одному проекту в моем решении. Все остальные проекты работают нормально и могут выполняться сколько угодно раз. Запирается только этот единственный проект.

Я нашел простое решение, которое мне подходит. Это выглядит так:

Когда возникает проблема, просто измените конфигурацию сборки вверху (если в «Выпуск» на «Отладка» и наоборот), выполните сборку, а затем вернитесь к предыдущей конфигурации и повторите сборку.

Я полагаю, что изменение конфигурации освобождает файлы vcshost и devenv.

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

... и все по-прежнему работало нормально.

Я сравнил исходный код моего оригинального .csproj; реальных отличий нет. И даже когда я попытался вернуться к предыдущей версии .csproj, он все равно работал.

Черная магия. Если работает, иногда лучше не спрашивать почему - просто прими это и двигайся дальше ...

РЕДАКТИРОВАТЬ: проблема является повторяющейся, и я считаю, что изолировал ее, когда я открываю конструктор формы абстрактной / общей формы во время компиляции.

Извлеченный урок: перед компиляцией убедитесь, что конструктор форм любых абстрактных или общих форм или элементов управления закрыт! Если нет, вам нужно закрыть VS и снова открыть!

Мы обнаружили здесь следующее: На странице свойств проекта на вкладке «Отладка» снимите флажок «Включить процесс хостинга Visual Studio». Я не уверен, для чего это свойство, но оно работает, если не отмечено флажком.

На самом деле вы должны захотеть установить флажок «Включить процесс хостинга Visual Studio». По крайней мере, для VS2010. А еще у меня есть:

если существует "$ (TargetPath) .locked" del "$ (TargetPath) .locked" если существует "$ (TargetPath)" если не существует "$ (TargetPath) .locked" move "$ (TargetPath)" "$ (TargetPath) .locked "

в параметрах предварительной сборки. Эта проблема преследовала меня очень долгое время, и только когда Джон В. упомянул этот флажок, я даже заметил, что он существует и низкий, и вот, он уже не отмечен.

Также обратите внимание, что -app-vshost.exe работает в фоновом режиме, даже если не выполняется отладка. Я думаю, именно поэтому он каждый раз успешно собирается и запускается. Раньше его не запускали. И я также попытался очистить папки отладки и выпуска и постоянно менять целевой тип, но ничего не работало, кроме описанного выше. Мое решение раньше заключалось в том, чтобы просто подождать 5 минут между сборками, что очень раздражало и требовало времени, чтобы что-то сделать. Я не видел никаких изменений в поведении, когда имело значение, какие вкладки открываются, или XNA против оконных форм или дизайнеров. Эта проблема возникла в 32-битных или 64-битных сборках, и не имело значения, убил ли я приложение с помощью ALT-F4 или убил его с помощью диспетчера задач, который теоретически не позволил бы приложению закрыть или освободить ресурсы. Сначала я подумал, что это проблема со сборкой мусора.

VS2017 - Решено путем закрытия всех экземпляров MSBuild.exe в диспетчере задач Windows.

Немного поздно ответить, но я решаю эту проблему, перейдя в свойства проекта> вкладка «Отладка»> снимите флажок «Включить процесс хостинга Visual Studio».

Я преодолел эту проблему, переименовав заблокированный файл (с помощью проводника Windows). Мне не разрешили удалить файл, но переименование заблокированного файла работает!

Я решил это, удалив папку bin \ Debug и, возможно, перезапустив VS

Для меня это была служба Windows, которая была установлена ​​и запущена. Как только я остановил его, сборка прошла успешно.

Выполните эту команду из окна Выполнить:

net stop iisadmin /y

а потом

iisreset

работал у меня. по сравнению с 2003 годом

Недавно столкнулся с этой проблемой при попытке создать решение, над которым я работаю (а не только проект winforms).
В дополнение к buildсбою, я заметил, что проекты очистки будут тихо терпеть неудачу (проверка папки bin показала, что файлы на самом деле не были удалены), а закрытие Visual Studio не завершило devenvпроцесс - скорее, оно привело к сбою. Затем процесс восстановления Windows перезапустит Visual Studio.

После некоторых проб и ошибок я обнаружил, что проблемы возникли со мной только тогда, когда я открыл решение из меню «Недавние» при запуске VS.
Открытие решения изFile >> Open >> Project/Solution обнаружилось, что оно работает как обычно.

В настоящее время не знаю почему - буду продолжать изучать это, но пока, по крайней мере, я могу работать!

Просто проверьте ссылки и удалите самостоятельную ссылку на проект.

Объяснение: Моя проблема началась после создания настраиваемого элемента управления и перетаскивания его на палитру панели инструментов для использования в формах дизайна. Сначала появилось предупреждение о том, что существует избыточность между исходным файлом настраиваемого элемента управления (.cs) и исполняемым файлом проекта (.exe). При выполнении / отладке появилась ошибка: невозможно получить доступ к (.exe), потому что он используется (и это было правдой).

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

У меня была такая же проблема с моим приложением Xamarin в Visual Studio, и она была решена путем отключения моего тестового мобильного устройства. Приложение было закрыто, а отладчик остановлен, но ошибка все еще возникала при попытке построить или перестроить решение. Он остановился только после того, как я отключил устройство, потому что мне нужно было получить звонок.

Просто чтобы добавить свои 2 цента. Моя проблема была решена открытием диспетчера задач и закрытием приложения. Он работал в фоновом режиме без каких-либо указаний на то, что он вообще работает (нет элементов на панели задач, нет пользовательского интерфейса, ничего), но я не уверен, почему это произошло. Очевидно, отладчик не работал, и в то время у меня был открыт только один экземпляр VS. Меня поражает, что это все еще происходит в VS 2017.

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

У меня была такая же проблема, и я не мог исправить ее, используя любой из методов, упомянутых в предыдущих ответах. Я решил проблему, убив все экземпляры «SSIS Debug Hist (32 bit)» в диспетчере задач и теперь работаю в обычном режиме.

Удаление папки Obj, Retail и отладки проекта .NET и повторная сборка снова помогли мне.

Как настроено ваше веб-приложение? Работает ли он под управлением Cassini (веб-сервер в трее) или IIS?

Однако обычно этого не должно происходить. Я думаю, что ProcessExplorer может сказать вам, какие файлы заблокировал процесс. Если нет, обработайте проводник, один из других инструментов sysinternals.

Прежде чем загружать один из инструментов SI, можно попробовать остановить веб-сервер Cassini и посмотреть, освободит ли это файл.

Что сработало для меня, так это перезапуск IIS

у меня была такая же проблема. изменение конфигурации отладки / выпуска не помогло. по крайней мере, без промежуточных строений.

в моем решении (winform) это было решено путем открытия основной формы winform в дизайнере. переход на код (F7). Затем закрываем код, закрываем конструктор winform и пересобираем все (ctrl-shift-B). Это сработало для меня.

похоже, что у какого-то дескриптора из приложения winform (которое запускает фоновый рабочий) все еще есть дескриптор файла в некоторых других используемых библиотеках.

У меня было два экземпляра Visual Studio, которые открыли одно и то же решение.

В моем случае было запущено несколько процессов vstest (с разными именами, но все они содержали строку vstest). Пришлось прекратить их в taskmgr.

Та же ошибка, решаемая обновлением пакетов поддержки Google Nuget

Когда я закончил процесс .Net Core Host, все построилось нормально. Мне не нужно было закрывать Visual Studio или что-то менять.

Для тех, кто разрабатывает VS с помощью Docker, перезапустите докер для службы Windows, и проблема будет немедленно решена.

Перед перезапуском докера я попробовал все упомянутые ответы, не нашел запущенного процесса msbuild.exe, также попытался перезапустить VS безрезультатно, работал только перезапуск докера.

Еще одно решение: когда файлы блокируются, сообщается о процессе блокировки (что-то вроде "ServiceHub.Host.CLR.x64 (7764)") с его идентификатором в скобках. Чтобы избавиться от процесса, откройте PowerShell (x + Win + I) и введите: «Stop-Process -Id idNumber».

Недавно я столкнулся с проблемой при развертывании в Service Fabric. Ошибка подразумевает, что «файл» уже используется, однако я обнаружил, что порт используется другой IDE. Остановив работающую службу, которая уже размещалась в порту, я смог предотвратить возникновение этого исключения.

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

Я решил эту проблему, закрыв соединение из обозревателя сервера и закрыв все вкладки, которые были открыты в Visual Studio.

Если это проект SSIS, откройте диспетчер задач и уничтожьте все экземпляры DtsDebugHost.exe, которые должны освободить заблокированные файлы.

Я использую Visual Studio Code и получил эту ошибку, потому что сервер разработки был запущен (я запустил сервер разработки, нажав Ctrl + F5).

Таким образом, я просто нажал на знак остановки, чтобы остановить его, и ошибка исчезла.

У меня была эта проблема (и это проблема, которую я видел в других местах, а не только в VS).

Это вызвано Dropbox (в моем случае). После редактирования кода и нажатия кнопки «Выполнить» иногда dropbox немедленно блокирует файл (чтобы он мог его обработать).

Решение 1. Просто снова нажмите "Выполнить".

Решение 2. Приостановить раскрывающийся список. (не очень хорошо, если вы используете Dropbox в качестве облачной резервной копии)

Решение 3. Удалите папку сборки из списка синхронизации dropboxes.