Visual Studio блокирует выходной файл на сборке

У меня есть простое решение WinForms в VS 2010. Всякий раз, когда я его строю, выходной файл (bin\debug\app.exe) заканчивается блокировкой, а последующие сборки терпят неудачу с сообщением типа "The process cannot access the file 'bin\Debug\app.exe' because it is being used by another process." Единственный способ построить проект - перезапустить VS после каждой сборки, что очень неудобно.

Я нашел это старое сообщение в блоге http://blogs.geekdojo.net/brian/archive/2006/02/17/VS2005FileLocking.aspx - кажется, что проблема действительно старая. Кто-нибудь знает, что здесь происходит, или, по крайней мере, обходное решение?

Обновление

Я действительно не запускаю файл. Блокировка происходит после сборки, а не после отладки (т.е. Запускать VS - build - build - fail!) И я попробовал отключить антивирус. Это не помогает.

Обновление 2

Process Explorer показывает файл devenv.exe, загрузив файл (в DLL, а не в дескрипторы). Кажется, что какой-то сбой во время сборки предотвратил разгрузку, но (первая) сборка завершается без каких-либо сообщений, кроме "1 успешно, o не удалось" /

Ответ 1

Я создал новое пустое решение и добавил к нему все старые файлы. Это как-то решило проблему.

Ответ 2

Имел ту же проблему, но нашел решение (спасибо Keyvan Nayyeri):

Но как это решить? Существуют различные способы, основанные на вашем типе проекта, но одно простое решение, которое я рекомендую разработчикам надстройки Visual Studio, заключается в том, чтобы добавить простой код в свои события создания проекта.

Вы можете добавить следующие строки кода в командную строку события pre-build вашего проекта.

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

Ответ 3

Это не проблема с вирусом. Это ошибка visual studio 2010. Похоже, что проблема связана с использованием visual studio gui designer.

Обходной путь здесь - переместить заблокированный выходной файл в другой временный в событии предварительной сборки. Имеет смысл генерировать временное имя файла случайным образом.

del "$(TargetPath).locked.*" /q 
if exist "$(TargetPath)"  move "$(TargetPath)" "$(TargetPath).locked.%random%"
exit /B 0

В случае использования постоянных временных имен файлов вы просто откладываете блокировки:

Этот метод работы работает ровно один раз

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

Я также нашел решение с 2 временными файлами, которые работают ровно 2 раза.

Ответ 4

Проблема возникла и у меня.

Моим сценарием было следующее: Запуск Windows 7 (но может также произойти в Windows XP), и во время работы над проектом с помощью UserFlow WPF я мог бы строить все время, пока не откроется XAML файл User Control - Оттуда, У меня есть одна сборка, а затем файлы заблокированы.

Кроме того, я заметил, что я запускал Visual Studio (Devenv.exe) в качестве администратора, Я начал запускать Visual Studio без прав администратора, и проблема исчезла..

Сообщите мне, помогло ли это вам. Удачи.

Ответ 5

Как насчет антивирусных сканеров на вашем компьютере? Вы можете увидеть какие-либо процессы, которые удерживают ручки в вашем файле (используйте Process Explorer, чтобы узнать)?

Возможно, в вашем списке процессов есть "app.exe", т.е. последняя версия, которую вы отлаживали, все еще работает? Когда вы разрабатываете приложения с несколькими потоками, это может произойти, если вы не join все из них.

Ответ 6

Я видел это как для жадного программного обеспечения для сканирования вирусов, так и для приложения app.exe. Убедитесь, что процесс еще не запущен.

Ответ 7

У меня была та же проблема, и я узнал, что VS только блокирует exe, когда я открывал Form или UserControl в VS перед тем, как строить. Решение было довольно простым, мне просто пришлось закрыть любую форму /UserControl, прежде чем я построю решение, и оно сработало.

Ответ 8

Существует также известная проблема 533411, где использование автоматического обновления номеров сборки может вызвать проблему блокировки. Обход из отчета об ошибке

Временное обходное решение будет отключать обновление версии сборки после восстановления. В файле AssemblyInfo.cs удалите wild card из атрибута AssemblyVersion, например:
замените это:
    [сборка: AssemblyVersion ( "1.4. *" )]
    [сборка: AssemblyFileVersion ( "1.4" )]
с этим:
    [сборка: AssemblyVersion ( "1.4.0.0" )]
    [сборка: AssemblyFileVersion ( "1.4.0.0" )]

Ответ 9

У меня возникла эта проблема и разрешил ее с помощью какого-то настраиваемого кода. См. Здесь: Проблемы с блокировкой файла сборки Visual Studio 2010

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

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

Ответ 10

Основываясь на замечании Stormenet, я выставил небольшой script, который должен работать во всех случаях.

Вот код, который нужно поместить в текстовое поле pre build event

$(SolutionDir)\BuildProcess\PreBuildEvents.bat  "$(TargetPath)"  "$(TargetFileName)"  "$(TargetDir)"  "$(TargetName)"

Pre build event

Вот script для копирования в файл $(SolutionDir)\BuildProcess\PreBuildEvents.bat (конечно, вы можете изменить этот путь):

REM This script is invoked before compiling an assembly, and if the target file exist, it moves it to a temporary location
REM The file-move works even if the existing assembly file is currently locked-by/in-use-in any process.
REM This way we can be sure that the compilation won't end up claiming the assembly cannot be erased!

echo PreBuildEvents 
echo  $(TargetPath) is %1
echo  $(TargetFileName) is %2 
echo  $(TargetDir) is %3   
echo  $(TargetName) is %4

set dir=C:\temp\LockedAssemblies

if not exist %dir% (mkdir %dir%)

REM delete all assemblies moved not really locked by a process
del "%dir%\*" /q

REM assembly file (.exe / .dll) - .pdb file - eventually .xml file (documentation) are concerned
REM use %random% to let coexists several process that hold several versions of locked assemblies
if exist "%1"  move "%1" "%dir%\%2.locked.%random%"
if exist "%3%4.pdb" move "%3%4.pdb" "%dir%\%4.pdb.locked%random%"
if exist "%3%4.xml.locked" del "%dir%\%4.xml.locked%random%"

REM Code with Macros
REM   if exist "$(TargetPath)"  move "$(TargetPath)" "C:\temp\LockedAssemblies\$(TargetFileName).locked.%random%"
REM   if exist "$(TargetDir)$(TargetName).pdb" move "C:\temp\LockedAssemblies\$(TargetName).pdb" "$(TargetDir)$(TargetName).pdb.locked%random%"
REM   if exist "$(TargetDir)$(TargetName).xml.locked" del "C:\temp\LockedAssemblies\$(TargetName).xml.locked%random%"

Ответ 11

Единственное, что сработало для меня, это выйти из Visual Studio 2012, удалить папки BIN и OBJ для проблем, связанных с проектом, и снова открыть Visual Studio.

Проблема решена... До следующего раза.

Ответ 12

Если ваш $(TargetPath) указывает на DLL, которая использует COM, убедитесь, что у вас есть конструктор по умолчанию. Не знаете, почему конструктор по умолчанию не выводится там. Добавление конструктора по умолчанию работало для меня в этом сценарии.

Ответ 13

Закрытие визуальной студии, повторное открытие и перезагрузка самого последнего решения помогает мне решить эту проблему. (Visual Studio 2013 Ultimate)

Ответ 14

Я столкнулся с тем же, что и разработки приложений xamarin в VS2017.

Случилось, что Windows Defender блокировал exe/dll с помощью devenv.exe.

Вы можете перейти в Win Defender и добавить

devenv.exe
msbuild.exe

в список исключений процессов.

Ответ 15

Это решение, которое я обнаружил

  • Снимите флажок процесса хостинга Visual Studio в настройках проекта, как показано ниже.

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

  1. Убейте exe. это будет ваше applicationname.vshost.exe из taskmanager

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

  1. Теперь вы можете восстановить приложение и запустить его.

Примечание. Вы можете снова включить этот параметр без проблем.

Ответ 16

Мне удалось устранить эту проблему, отключив сканирование в реальном времени McAfee LiveSafe. Мой .exe файл будет заблокирован, как описано в OP, и у меня не было бы способа удалить этот файл, а это значит, что я не смог собрать решение. После отключения функции McAfee проблема исчезла.

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