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

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

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

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

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

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

EDIT: Еще одно интересное открытие: мне даже не нужно запускать приложение. Просто компиляция его однажды вызывает блокировку файла; Я не могу скомпилировать дважды подряд!

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

Ответ 1

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

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

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

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

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

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

Ответ 2

Я нашел простое решение, которое работает для меня. Это происходит следующим образом:

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

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

Ответ 3

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

Ответ 4

На самом деле вам нужно установить флажок "Включить хостинг Visual Studio". По крайней мере, для VS2010. И у меня также есть:

если существует "$ (TargetPath).блокировано" del "$ (TargetPath).блокировано" если существует "$ (TargetPath)", если не существует "$ (TargetPath).блокировано" move "$ (TargetPath)" "$ (TargetPath).блокировано"

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

Ответ 10

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

net stop iisadmin /y

а затем

iisreset

работал у меня. vs 2003

Ответ 11

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

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

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

Ответ 12

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

Ответ 13

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

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

Ответ 14

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

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

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

Ответ 15

Для меня работала перезагрузка IIS

Ответ 16

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

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

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

Ответ 17

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

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

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

Ответ 18

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

Ответ 19

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

Ответ 20

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

Я изменил строку кода, которая явно закрывает мое приложение от Application.Exit до System.Windows.Forms.Application.Exit, и теперь оно работает. Возможно, это сработает и для вас. Приветствия.

Ответ 21

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

Ответ 22

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

Ответ 23

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

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

Ответ 24

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

Ответ 25

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

Ответ 26

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

Ответ 27

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