Visual Studio „Nie można skopiować”… podczas kompilacji

Wciąż pojawia się ten błąd podczas kompilacji mojego projektu 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.    

Teraz odkryłem, że zabicie tego procesu

Weingartner.WeinCad.vhost.exe

działa (czasami), ale to działa mi na nerwy. W jakikolwiek sposób można temu zapobiec?

Moje ustawienia debuggera to

W programie Visual Studio 2013 napotkałem podobne komunikaty o błędach.

Najczęściej stwierdziłem, że taka sytuacja miała miejsce, gdy proces debugowania został zatrzymany z powodu wyjątku.

Kiedy clean + build nie rozwiązał dla mnie tego problemu, odniosłem sukces, wykonując następujące czynności:

• Zamykanie programu Visual Studio
• Usuwanie biniobj foldery, a
• Ponowne otwarcie programu Visual Studio.

Ten „błąd” istnieje od Visual Studio 2003.

Wreszcie stwierdziłem, że często mogę rozwiązać ten problem, po prostu zmieniając nazwę pliku wykonywalnego, a następnie usuwając go.

W programie Visual Studio Premium 2013 (aktualizacja 3) rozwiązałem to za pomocą jednego kompilatora:

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

To z wdziękiem usuwa wszystkie stare pliki PDB (jeśli to możliwe), a następnie zmienia nazwę wszystkiego, co pozostało z .old.pdbrozszerzeniem. Przyjemnym efektem ubocznym jest to, że jeśli stary PDB jest nadal zablokowany, to po prostu dodaje kolejny .old kawałek do nazwy pliku i wszystkie one są czyszczone przy następnym uruchomieniu Visual Studio i kompilacji.

Na przykład sesja kompilacji / debugowania 1 pozostanie MyProject.pdbzablokowana.
Następnym razem, gdy zbudujesz:
MyProject.pdb->MyProject.old.pdb

Następnie build / debug sesja 2 rozpoczyna się, a obie MyProject.pdb i MyProject.old.pdbsą nadal zablokowane
MyProject.old.pdb-> MyProject.old.old.pdb
MyProject.pdb->MyProject.old.pdb

Wreszcie, ponowne uruchomienie Visual Studio i wykonanie nowej kompilacji pozbędzie się ich obu i będzie kontynuowało proces jak zwykle.

Wynika to z faktu, że aplikacja została zamknięta, ale nadal działa w tle.

Rozwiązanie tymczasowe:

• Przejdź do Menedżera zadań ( Ctrl+ Alt+ Esc).
• Przejdź do zakładki Procesy i znajdź „YourProjectName.exe”.
• Zaznacz „Pokaż procesy od wszystkich użytkowników”, jeśli nie możesz znaleźć swojego procesu.
• Zakończ Przetwarzaj.

Stałe rozwiązanie: musisz zamknąć aplikację za pomocą kodowania. Oto kod ...

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

Musisz umieścić ten kod we wszystkich wydarzeniach zamykających formularz. Przykład:

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

.vhost.exe to proces debugowania, więc wygląda na to, że debugowany proces nie został poprawnie zamknięty. Możliwe, że masz błąd, który utrzymuje go przy życiu i nie zatrzymuje poprawnie procesu debugowania - istnieją opcje, aby odłączyć się od procesu, gdy klikniesz „przestań debugować” zamiast faktycznie zabić debugera, więc może masz ten zestaw.

Ale to jest problem - plik, który próbujesz skopiować, jest zablokowany (tzn. Nadal używany) przez system operacyjny, więc uniemożliwia kopiowanie. Upewnij się, że plik jest bezpłatny, a będziesz mógł skopiować.

Rozwiązałem go, zabijając IISExpress w menedżerze zadań

Powinieneś wyłączyć swój program antywirusowy (szczególnie jeśli jest to Avast) i spróbować ponownie. Pomogło mi to. Problem polega na tym, że debugger / konstruktor tworzy plik .exe, który jest identyfikowany przez Avast jako zagrożenie i dlatego jest usuwany tuż przed jego wykonaniem przez VS.

Byłem w stanie rozwiązać ten problem (VS 2010), dostarczając następujące działania przed kompilacją;

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

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

Zacytować:

Obejściem tego problemu jest umieszczenie tego we właściwości wiersza polecenia Zdarzenie przed kompilacją> projektu (na karcie Zdarzenia kompilacji):

Fragment kodu

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

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

Wyjątek

W niektórych przypadkach w programie Visual Studio, gdy (Build || Rebuild) działa na IISExpress, masz do czynienia z tym wyjątkiem:

Nie można skopiować pliku „obj \ Debug \ YourProjectName.dll" do bin \ YourProjectName.dll ". Proces nie może uzyskać dostępu do pliku„ bin \ YourProjectName.dll ”, ponieważ jest on używany przez inny proces

Rozwiązanie

1. Kliknij prawym przyciskiem myszy projekt internetowy, który musi zostać zbudowany.
2. Kliknij na właściwości.
3. Wybierz kartę Zbuduj zdarzenia po lewej stronie.
4. W wierszu polecenia Zdarzenia przed kompilacją wklej te 2 linie:

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

Jesteś dobry 2 GO!

Wygląda na to, że zmiana nazwy zestawu projektu rozwiązuje problem.

Więc zamiast tego

Zmieniam to na to

Zauważ, że po prostu zmienił go od Increment and Recallcelu Increment_Recall, po prostu usuwa spacje. Teraz działa mi dobrze.

Zabicie procesu w3wp.exe (IIS) często to rozwiąże.
Zasadniczo możesz poznać proces, który ma blokadę pliku, przechodząc do folderu bin i próbując go usunąć. Komunikat o błędzie, który się pojawi, w przypadku, gdy inny proces go używa, będzie zawierać nazwę procesu, który należy zabić.

Napotkałem ten sam problem w wersji VS 2012 11.0.60610.01 Update 3 na Windows 8

Nie było otwartych okien projektantów, a projekt był prostą aplikacją konsolową.

Usunięcie procesu vshost uzyskującego dostęp do pliku nie działa przez większość czasu, ponieważ proces nie uzyskuje dostępu do pliku.

Najprostszym obejściem, które działa i zajmuje najmniej czasu, jest usunięcie projektu z rozwiązania, zbudowanie innego projektu w rozwiązaniu, a następnie dodanie oryginału z powrotem.

Jest to irytujące i strata czasu, ale jest najtańsze ze wszystkich innych opcji, które znam.

Mam nadzieję że to pomoże...

Myślę, że rozwiązałem to, usuwając znacznik wyboru Break all processes when one process breaksw opcjach debugowania (pierwszy zrzut ekranu op -> druga opcja).
Od jakiegoś czasu go odznaczam.
Używam MySql NET Connector i formantów DevExpress w moim projekcie. Być może jednym z nich nie było usuwanie połączeń, powiązań itp. Z powodu aktywacji tej flagi.

EDYCJA: zdecydowanie działa! Koniec z „Nie można skopiować pliku” i nie ma już błędów projektanta formularzy.

Dodaj zdarzenie przed kompilacją swojego głównego projektu taskkill / f / fi "pid gt 0" / im "YourProcess.vshost.exe"

Mój wkład 10 centów.

Nadal mam ten problem od czasu do czasu w aktualizacji VS 2015 Update 2.

Odkryłem, że zmiana celu kompilacji rozwiązuje problem.

Spróbuj tego: jeśli jesteś w trybie DEBUG, przełącz się na RELEASE i buduj, a następnie z powrotem do DEBUG. Problem zniknął.

Stefano

Wykonaj poniższe kroki

1. Otwórz Menedżera zadań (Ctrl + Alt + Delete)
2. W zakładce Wydajność wybierz < ProjectNameOfYours.exe >.
3. Kliknij Zakończ proces.
4. Teraz Zbuduj rozwiązanie.

Powyższe kroki rozwiązały błąd na stałe :)

Jeśli żadna z odpowiedzi nie działa, spróbuj tego prostego sprawdzenia. Znajdź dowolny MSbuild.exe uruchomiony i trzymający plik EXE projektu. Zabij MSBuild.exe i powinieneś być gotowy.

Nie mogę podać rozwiązania, które mogłoby temu zapobiec, ale przynajmniej ZMIEŃ NAZWĘ zablokowanego pliku (Eksplorator Windows lub klasyczne okno poleceń), a następnie skompiluj / skompiluj. Nie ma potrzeby ponownego uruchamiania lub ponownego uruchamiania VS201x. Z pewnym doświadczeniem możesz dodać skrypt przed kompilacją, aby usunąć stare pliki lub zmienić nazwę, a następnie usunąć z drogi w przypadku blokady.

Zobacz inną odpowiedź . Zasadniczo procesy MSBuild.exe mogą być uruchomione w tle i zużywają pliki zasobów. Jeśli masz jakieś zadania przed lub po kompilacji, które powodują, że MSBuild jest uruchamiany za pomocą wiersza poleceń, spróbuj dodać flagę „/ nr: false” do tego polecenia. Ale ponownie zobacz poprzednią odpowiedź, aby uzyskać bardziej szczegółowe informacje.

W końcu jak to naprawić. Dlaczego nie możemy kontynuować debugowania po pierwszym debugowaniu, ponieważ exe pierwszego debugowania wciąż działa. Aby po pierwszym debugowaniu przejść do Menedżera zadań -> Karta Proces -> [nazwa projektu exe] zakończyć proces exe.

mi to pasuje :)

Odpowiedź @ Geoffa ( https://stackoverflow.com/a/25251766/3739540 ) jest dobra, ale generuje kod błędu 1 podczas ponownej kompilacji.

Oto, co zadziałało dla mnie (2> nul 1> nul na końcu + wyjście 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

Jeśli debugujesz szablony T4 , dzieje się tak przez cały czas. Moje rozwiązanie (zanim MS to naprawi) byłoby po prostu zabić ten proces:

Menedżer zadań -> Użytkownik -> T4VSHostProcess.exe

Ten proces pojawia się tylko podczas debugowania szablonu T4, a nie podczas uruchamiania.

Oto skrypt, aby zdecydowanie pozbyć się tego problemu:

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

Skrypt należy wywoływać z każdego zdarzenia przed kompilacją projektu VS.

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

1. Otwórz właściwości projektu [menu> projekt> właściwości]
2. Wybierz kartę „debuguj”
3. Odznacz „Włącz proces hostingu studio wizualnego”
4. Rozpocznij debugowanie [F5]
5. Otrzymasz ostrzeżenie bezpieczeństwa, po prostu „ok”. Pozwala na uruchomienie aplikacji
6. Przestań debugować.
7. Zaznacz opcję „Włącz proces hostingu Visual Studio” na karcie debugowania,
8. Teraz spróbuj rozpocząć debugowanie, błąd nie będzie już wyświetlany

[Pracuj dla mnie]

To pytanie było pierwszym wynikiem, gdy szukałem następującego błędu:

Nie można skopiować pliku „...”, ponieważ nie został znaleziony.

podczas budowania w Visual Studio 2013 (aktualizacja 3).

Rozwiązanie: Odinstalowanie „narzędzi zwiększających wydajność” w programie Visual Studio 2013.

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

W moim przypadku był to biegacz Resharper Unit Tests (plus testy NUnit, nigdy nie miałem takiego problemu z MsTests). Po zabiciu procesu był w stanie go odbudować bez ponownego uruchamiania systemu operacyjnego lub VS2013

Nie zdawałem sobie sprawy, że wciąż mam podłączony debuger i próbowałem zbudować w tej samej instancji Visual Studio. Po zatrzymaniu debugera byłem w stanie zbudować.

Zabicie procesu (ów) vstest.executionengine.exe rozwiązuje ten problem w 90% przypadków. Jeśli to nie zadziała, zabij także QTAgent32.exe a następnie usunięcie folderów / bin i / obj dla danego projektu.

To najbardziej irytująca część mojego dnia pracy. :)

Dla mnie był to program antywirusowy Avast, który nie pozwala programowi Visual Studio na pisanie / odczytywanie / uruchamianie pliku. Musiałem więc dodać folder Visual studio 2010/2012 do listy wykluczeń antywirusowych. A zaraz po tym baam ... działa.

Upewnij się, że zamknąłeś wszystkie instancje wcfSvcHost i spróbuj ponownie. To zadziałało dla mnie!