Ответ 1
Я создал новое пустое решение и добавил к нему все старые файлы. Это как-то решило проблему.
У меня есть простое решение 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 не удалось" /
Я создал новое пустое решение и добавил к нему все старые файлы. Это как-то решило проблему.
Имел ту же проблему, но нашел решение (спасибо 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"
Это не проблема с вирусом. Это ошибка 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 раза.
Проблема возникла и у меня.
Моим сценарием было следующее: Запуск Windows 7 (но может также произойти в Windows XP), и во время работы над проектом с помощью UserFlow WPF я мог бы строить все время, пока не откроется XAML файл User Control - Оттуда, У меня есть одна сборка, а затем файлы заблокированы.
Кроме того, я заметил, что я запускал Visual Studio (Devenv.exe) в качестве администратора, Я начал запускать Visual Studio без прав администратора, и проблема исчезла..
Сообщите мне, помогло ли это вам. Удачи.
Как насчет антивирусных сканеров на вашем компьютере? Вы можете увидеть какие-либо процессы, которые удерживают ручки в вашем файле (используйте Process Explorer, чтобы узнать)?
Возможно, в вашем списке процессов есть "app.exe", т.е. последняя версия, которую вы отлаживали, все еще работает? Когда вы разрабатываете приложения с несколькими потоками, это может произойти, если вы не join
все из них.
Я видел это как для жадного программного обеспечения для сканирования вирусов, так и для приложения app.exe. Убедитесь, что процесс еще не запущен.
У меня была та же проблема, и я узнал, что VS только блокирует exe, когда я открывал Form или UserControl в VS перед тем, как строить. Решение было довольно простым, мне просто пришлось закрыть любую форму /UserControl, прежде чем я построю решение, и оно сработало.
Существует также известная проблема 533411, где использование автоматического обновления номеров сборки может вызвать проблему блокировки. Обход из отчета об ошибке
Временное обходное решение будет отключать обновление версии сборки после восстановления. В файле AssemblyInfo.cs удалите wild card из атрибута AssemblyVersion, например:
замените это:
[сборка: AssemblyVersion ( "1.4. *" )]
[сборка: AssemblyFileVersion ( "1.4" )]
с этим:
[сборка: AssemblyVersion ( "1.4.0.0" )]
[сборка: AssemblyFileVersion ( "1.4.0.0" )]
У меня возникла эта проблема и разрешил ее с помощью какого-то настраиваемого кода. См. Здесь: Проблемы с блокировкой файла сборки Visual Studio 2010
Скомпилируйте утилиту в принятом ответе и ссылайтесь на нее во время шага сборки, как описано для решения этой проблемы. Я по-прежнему отключил VS 2010 на обед, чтобы очистить утреннюю работу.
Причиной для пользовательского кода было то, что часто рекомендуемое решение работало только один раз, а затем переименованные файлы также были заблокированы, что предотвращало переименование. Здесь мы просто добавляем информацию о времени данных в файл, чтобы переименованные версии не могли конфликтовать.
Основываясь на замечании Stormenet, я выставил небольшой script, который должен работать во всех случаях.
Вот код, который нужно поместить в текстовое поле pre build event
$(SolutionDir)\BuildProcess\PreBuildEvents.bat "$(TargetPath)" "$(TargetFileName)" "$(TargetDir)" "$(TargetName)"
Вот 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%"
Единственное, что сработало для меня, это выйти из Visual Studio 2012, удалить папки BIN и OBJ для проблем, связанных с проектом, и снова открыть Visual Studio.
Проблема решена... До следующего раза.
Если ваш $(TargetPath) указывает на DLL, которая использует COM, убедитесь, что у вас есть конструктор по умолчанию. Не знаете, почему конструктор по умолчанию не выводится там. Добавление конструктора по умолчанию работало для меня в этом сценарии.
Закрытие визуальной студии, повторное открытие и перезагрузка самого последнего решения помогает мне решить эту проблему. (Visual Studio 2013 Ultimate)
Я столкнулся с тем же, что и разработки приложений xamarin в VS2017.
Случилось, что Windows Defender блокировал exe/dll с помощью devenv.exe.
Вы можете перейти в Win Defender и добавить
devenv.exe
msbuild.exe
в список исключений процессов.
Это решение, которое я обнаружил
Примечание. Вы можете снова включить этот параметр без проблем.
Мне удалось устранить эту проблему, отключив сканирование в реальном времени McAfee LiveSafe. Мой .exe файл будет заблокирован, как описано в OP, и у меня не было бы способа удалить этот файл, а это значит, что я не смог собрать решение. После отключения функции McAfee проблема исчезла.
Затем я, конечно же, продолжил полностью удалять McAfee, который был установлен только потому, что мой компьютер является новым, и он пришел с уже установленной программой.