Visual Studio «Не удалось скопировать»… во время сборки

Я продолжаю получать эту ошибку во время сборки моего проекта VS2012 C #

Error   41  Could not copy "obj\Debug\WeinGartner.WeinCad.exe" to
 "bin\Debug\WeinGartner.WeinCad.exe". 
 Exceeded retry count of 10. Failed.    


Error   42  Unable to copy file "obj\Debug\WeinGartner.WeinCad.exe" to
"bin\Debug\WeinGartner.WeinCad.exe". The process cannot access the file
'bin\Debug\WeinGartner.WeinCad.exe' because it is being used by another 
process.    

Теперь я понял, что убивает процесс

Weingartner.WeinCad.vhost.exe

работает (иногда) но это действует мне на нервы. Есть ли способ остановить это вообще?

Мои настройки отладчика

Я встречал похожие сообщения об ошибках в Visual Studio 2013.

В основном я обнаружил, что такая ситуация возникла, когда процесс отладки был остановлен из-за исключения.

Когда clean + build не решил эту проблему для меня, я добился успеха, выполнив следующие действия:

• Закрытие Visual Studio
• Удаление binи objпапки, и
• Повторное открытие Visual Studio.

Эта «ошибка» существует со времен Visual Studio 2003.

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

В Visual Studio Premium 2013 (обновление 3) я решил эту проблему с помощью предварительной сборки одной строки:

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

Это изящно удаляет все старые файлы PDB (если это возможно), а затем переименовывает все, что осталось с .old.pdbрасширением. Приятным побочным эффектом является то, что если старая PDB все еще заблокирована, она просто добавляет еще один элемент .old к имени файла, и все они очищаются при следующем перезапуске Visual Studio и выполнении сборки.

Например, сеанс сборки / отладки 1 остается MyProject.pdbзаблокированным.
В следующий раз вы построите:
MyProject.pdb->MyProject.old.pdb

Затем запускается сеанс сборки / отладки 2, и оба так MyProject.pdb и MyProject.old.pdbостаются заблокированными:
MyProject.old.pdb-> MyProject.old.old.pdb
MyProject.pdb->MyProject.old.pdb

Наконец, перезапуск Visual Studio и создание новой сборки избавят от обоих этих факторов и продолжат процесс как обычно.

Это потому, что вы закрыли свое приложение, но оно все еще работает в фоновом режиме.

Временное решение:

• Перейти к диспетчеру задач ( Ctrl+ Alt+ Esc).
• Перейдите на вкладку «Процессы» и найдите «YourProjectName.exe».
• Установите флажок «Показать процессы от всех пользователей», если вы не можете найти свой процесс.
• Завершить процесс.

Постоянное решение: вы должны закрыть приложение через кодирование. Вот код ...

System.Windows.Forms.Application.Exit();

Вы должны поместить этот код в событие закрытия формы во всей форме. Пример:

private void frm_menu_FormClosing(object sender, FormClosingEventArgs e)
{
    System.Windows.Forms.Application.Exit();
}

.vhost.exe - это процесс отладчика, поэтому кажется, что отлаживаемый процесс не закрылся должным образом. Скорее всего, у вас есть ошибка, которая поддерживает ее и неправильно останавливает процесс отладки - есть варианты отсоединения от процесса, когда вы нажимаете «остановить отладку» вместо того, чтобы фактически убить отладчик, так что, возможно, у вас есть этот набор.

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

Я решил это, убив IISExpress в диспетчере задач

Вы должны отключить антивирус (особенно, если это Avast) и повторить попытку. Это помогло мне. Проблема заключается в том, что отладчик / сборщик создает файл .exe, который определен Avast как угроза, и поэтому удаляется непосредственно перед его выполнением VS.

Я смог исправить эту проблему (VS 2010), предоставив следующие действия перед сборкой;

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

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

Quote:

Обходной путь должен поместить это в свойство командной строки события Pre-build проекта> (во вкладке Events build):

Фрагмент кода

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

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

исключение

В некоторых случаях в Visual Studio, когда вы (Build || Rebuild) поверх запуска IISExpress, вы сталкивались с этим исключением:

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

Решение

1. Щелкните правой кнопкой мыши по веб-проекту, который нужно построить.
2. Нажмите на свойства.
3. Выберите вкладку Build Events с левой стороны.
4. В командной строке Pre-build events вставьте эти 2 строки:

tasklist /fi "imagename eq iisexpress.exe" |find ":" > nul
if errorlevel 1 taskkill /f /im "iisexpress.exe"

Вы хороши 2 GO!

Похоже, что при изменении имени сборки проект решает проблему.

Так что вместо этого

Я изменил это на это

Обратите внимание, что я просто изменил его с Increment and Recallна Increment_Recall, я просто удалил пробелы. Теперь он работает нормально для меня.

Завершение процесса w3wp.exe (IIS) часто решает эту проблему.
Как правило, вы можете узнать процесс, который заблокировал файл, перейдя в папку bin и попытавшись удалить ее. Сообщение об ошибке, которое появится, если другой процесс использует его, будет содержать имя процесса, который необходимо уничтожить.

Я столкнулся с той же проблемой на VS 2012 Версия 11.0.60610.01 Обновление 3 на Windows 8

Дизайнерских окон не было открыто, и проект представлял собой простое консольное приложение.

Удаление процесса vshost, обращающегося к файлу, не работает большую часть времени, так как процесс не обращается к файлу.

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

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

Надеюсь это поможет...

Я думаю, что решил эту проблему, сняв флажок Break all processes when one process breaksв параметрах отладки (первый снимок экрана -> второй вариант).
Некоторое время он строился / работал хорошо, так как я снял его.
В моем проекте используются элементы управления MySql NET Connector и DevExpress. Может быть, один из них не выбрасывал связи, привязки и т. Д., Потому что этот флаг активирован.

Отредактировано: определенно это работает! Больше нет «Невозможно скопировать файл» и больше нет ошибок дизайнера форм.

Добавьте в pre-build событие вашего мастер-проекта taskkill / f / fi "pid gt 0" / im "YourProcess.vshost.exe"

Мой вклад в 10 центов.

Я до сих пор иногда сталкиваюсь с этой проблемой в VS 2015 Update 2.

Я обнаружил, что переключение цели компиляции решает проблему.

Попробуйте это: если вы находитесь в DEBUG, переключитесь на RELEASE и соберите, затем вернитесь к DEBUG. Проблема ушла.

Стефано

Выполните следующие шаги

1. Открыть диспетчер задач (Ctrl + Alt + Delete)
2. На вкладке « Быстродействие » выберите « ProjectNameOfYours.exe» .
3. Нажмите на Завершить процесс.
4. Теперь создайте решение.

Вышеуказанные шаги исправили ошибку навсегда :)

Если ни один из ответов не работает, попробуйте эту простую проверку. Найдите для любого MSbuild.exe работающего и удерживающего ваш EXE-файл проекта. Убейте MSBuild.exe и вам будет хорошо идти.

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

Смотрите этот другой ответ . По сути, вы могли бы запускать процессы MSBuild.exe в фоновом режиме, используя файлы ресурсов. Если у вас есть какие-либо задачи до или после сборки, из-за которых MSBuild запускается через командную строку, попробуйте добавить к этой команде флаг «/ nr: false». Но опять же, смотрите предыдущий ответ для более подробной информации.

Я наконец то как это исправить. Почему мы не можем продолжить отладку после первой отладки, потому что первый exe отладки все еще работает. Чтобы после первой отладки вам нужно было перейти в Диспетчер задач -> Вкладка «Процесс» -> [имя вашего проекта exe] и завершить процесс exe.

меня устраивает :)

Ответ @ Джеффа ( https://stackoverflow.com/a/25251766/3739540 ) хорош, но выдает код ошибки 1 при перекомпиляции.

Вот что у меня сработало (2> nul 1> nul на конце + выход 0):

(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb) 2>nul 1>nul
(if exist "$(TargetDir)*old.dll" del "$(TargetDir)*old.dll") & (if exist "$(TargetDir)*.dll" ren "$(TargetDir)*.dll" *.old.dll) 2>nul 1>nul
exit 0

Если вы отлаживаете шаблоны T4 , это происходит постоянно. Мое решение (до того, как MS исправит это) было бы просто убить этот процесс:

Диспетчер задач -> Пользователь -> T4VSHostProcess.exe

Этот процесс запускается только при отладке шаблона T4, а не при его запуске.

Вот сценарий, чтобы определенно избавиться от этой проблемы:

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 and 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%"

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

REM References:
REM   http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx
REM   http://stackoverflow.com/a/2738456/27194
REM   http://stackoverflow.com/a/35800302/27194

Сценарий должен вызываться из каждого события предварительной сборки проекта VS.

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

1. Открыть свойства проекта [меню> проект> свойства]
2. Выберите вкладку «отладка»
3. Снимите флажок «Включить процесс размещения визуальной студии»
4. Начать отладку [F5]
5. Вы получите предупреждение системы безопасности, просто «хорошо». Позволяет приложению работать
6. Прекратите отладку.
7. Установите флажок «Включить процесс размещения Visual Studio» на вкладке отладки,
8. Теперь попробуйте начать отладку, вы больше не увидите ошибку

[Работа для меня]

Этот вопрос был первым результатом при поиске следующей ошибки:

Не удалось скопировать файл "...", поскольку он не был найден.

при сборке в Visual Studio 2013 (обновление 3).

Решение: удаление «Power Tools» в Visual Studio 2013.

https://connect.microsoft.com/VisualStudio/feedback/details/533411

В моем случае это был бегун Resharper Unit Tests (плюс тесты NUnit, у которых никогда не было такой проблемы с MsTests). Убив процесс, смог перестроить процесс, не перезагружая ОС или VS2013

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

Убийство процесса (ов) vstest.executionengine.exe решает эту проблему для меня 90% времени. Если это не сработает, то также убивает QTAgent32.exe и затем удаляет папки / bin и / obj для рассматриваемого проекта.

Это самая раздражающая часть моего рабочего дня. :)

Для меня это был антивирус Avast, который не позволял Visual Studio записывать / читать / выполнять файл. Поэтому мне пришлось добавить папку Visual studio 2010/2012 в список исключений антивируса. И сразу после этого баама ... это работает.

Убедитесь, что вы закрыли все экземпляры wcfSvcHost и попробуйте снова. Это сработало для меня!