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

347

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

wprowadź opis zdjęcia tutaj wprowadź opis zdjęcia tutaj

bradgonesurfing
źródło
Dla mnie było to spowodowane ręcznie uruchomionym plikiem .exe w katalogu Release. Problem polegał na tym, że VS nie może skopiować pliku wykonywalnego, który jest nadal uruchomiony. Spróbuję to naprawić, odpowiednio usuwając zasoby, aby program nie pozostawał zawieszony po zamknięciu okna.
lahjaton_j
Istnieje dobre podsumowanie tego problemu wraz z typowymi krokami do rozwiązania w tym pytaniu
LightCC
Działo się to dla mnie, ponieważ Windows Defender zdecydował, że nie podoba mu się już .exe z projektu VS2019, nad którym pracuję. Pracowałem nad tym od tygodni bez problemu, ale dziś zgadnij, że nowa aktualizacja nie spodobała się. Musiałem wykluczyć moje foldery źródłowe. Przestał się dziać.
IronRod

Odpowiedzi:

401

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.

Gerard
źródło
8
To samo tutaj, VS2013. Zamykanie, usuwanie artefaktów kompilacji, restartowanie -> wszystko w porządku.
cacau
49
mam ten sam problem, ale po ponownym uruchomieniu VS dostaję jedną kompilację, a pliki są ponownie blokowane ..
Sonic Soul
54
To nie jest rozwiązanie, w najlepszym razie częściowe. Nie chcę restartować VS co 10min. Czyszczenie rozwiązania działa dla mnie, ale czyszczenie go co 10 minut również nie jest rozwiązaniem.
Legendy,
7
Z mojego doświadczenia wynika, że ​​VS2013 robi to dla mnie co najmniej 10 razy dziennie, bez względu na to, na jakiej maszynie pracuję. To tak, jakby błąd się pogorszył. Tylko mówię
AR
28
błąd nadal istnieje w VS 2019.
Akash KC
107

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.

Geoff
źródło
5
To samo w VS2010, VS 2012
Boogier
7
Dziękuję, działało dla mnie idealnie, modyfikując twój przykład do używania plików exe. Myślę, że może to być błąd również w najnowszym CTP VS 2015.
Johny Skovdal
Cieszę się, że pomogło - wciąż mam ustawione polecenie przed kompilacją i działa wystarczająco dobrze, że zapomniałem, że tam było!
Geoff
3
Nienawidzę tego robić, ale to działa, więc jest! :) Dzięki za udostępnienie tej perły, Geoff!
kayleeFrye_onDeck
1
Najnowsze (2018-03-11) Visual Studio 2017 v15.6.1: wciąż problem. Debugowanie, wyjątek, zestawy w katalogu docelowym zablokowane. Powyższe rozwiązanie z * .pdb zmieniono na * .dll nadal obowiązuje.
Michiel de Wolde
71

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();
}
Rushi Daxini
źródło
1
To było dokładnie to. Visual Studio uległo awarii i IIS Express nadal działa (w moim przypadku). Wszystko, co musiałem zrobić, to otworzyć pasek zadań i kliknąć prawym przyciskiem myszy ikonę IIS Express i wyjść. Dziękuję Ci.
the-nick-wilson
To zadziałało dla mnie; Nie mogłem usunąć folderów obj i bin, ponieważ inny proces ich używał. Na szczęście Windows 10 tak naprawdę powiedział, jak się nazywa; po zamknięciu w Menedżerze zadań problemy
zniknęły
25

.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ć.

gbjbaanb
źródło
Do pytań dodałem opcje debugowania. Jestem pewien, że to powinno zabić proces, ale może nie rozumiem niektórych opcji.
bradgonesurfing
W Visual Studio 2019, jestem coraz podobną wiadomość, choć teraz wspomina proces w niektórych wyjścia (nie wszystkie). To był testhost.x86.exe, który musiałem zabić za pośrednictwem Task Manager. Potem wydawało się, że przestał wykrywać jeden z procesów testowych.
Andez
23

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

pat capozzi
źródło
20

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.

Pitrs
źródło
Dobry chwyt Zawsze nienawidzę Avast.
stackunderflow
Avast też był dla mnie problemem. Odpowiedzią było wyłączenie osłony systemu plików. Próbowałem dodać folder Visual Studio \ Projects do Wykluczeń, ale to nie działało.
KeithB
1
Mam ten sam problem z ochroną Symantec Endpoint. Ktoś z działu IT podniósł poziom bezpieczeństwa całkiem wysoko :-) Dzięki, Pitrs.
ssimm
Dodam, że możesz stworzyć wyjątek dla katalogu obj \ Debug dla wygodnego używania, zamiast wyłączania AV lub jednego z jego narzędzi ochronnych.
A. Kali,
Dzięki! Odkryłem, że to MalwareBytes blokuje mój plik .exe.
NL3294,
15

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"
Nair
źródło
1
@luckyluke, we właściwościach projektu znajduje się sekcja, w której można dodać skrypt przed kompilacją. Skopiuj i wklej powyższy skrypt w wyznaczonym obszarze i przebuduj projekt / uruchom aplikację
Nair
13

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"
Zheng Qiang
źródło
8

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!

Xaimaran
źródło
6

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

Więc zamiast tego

wprowadź opis zdjęcia tutaj

Zmieniam to na to

wprowadź opis zdjęcia tutaj

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

Cary Bondoc
źródło
6

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ć.

Ogglas
źródło
4

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...

Ashwin J
źródło
Wszystko, co musisz zrobić, to Przebuduj wszystko i wszystko jest w porządku przez kolejne 10 prób. Niewielka niedogodność.
Scott Shaw-Smith
@ Scott Shaw-Smith Nie działa dla mnie. I w oparciu o niektóre inne komentarze, które widziałem, to też nie działa dla innych. W moim przypadku odinstalowanie Avast naprawiło to.
user316117,
4

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.

Ivan Ferrer Villa
źródło
1
Żadne inne rozwiązanie nie działało dla mnie. To jest jedyny. Korzystam z programu Visual Studio 2017 13.2
xleon
4

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

sofsntp
źródło
Naprawdę nie lubię tak rozwiązywać problemu, ale zadziałało!
Petter T
Znalazłem to najprostsze działające rozwiązanie problemu.
dscharge
4

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

Stefano.net
źródło
Tak! Otóż ​​to. To proste rozwiązanie tego irytującego problemu! Totally dla mnie pracował. Łatwo i szybko! Wielkie dzięki.
Meister Schnitzel
1
Mi to pasuje! Wskazówka: Przy dezaktywowanym debugowaniu >> Opcje >> Debugowanie >> Ogólne >> „Użyj zarządzanego trybu zgodności” obejście nie jest wymagane!
leon22,
4

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 :)

Akshay Bagi
źródło
4

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.

Pan
źródło
2

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.

hopperpl
źródło
2

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.

Josh Pavoncello
źródło
Snap, mam ten sam problem w aktualizacji VS2015 2 - MSBuild, proces exe musi zostać zabity w TaskManager, zanim będę mógł ponownie zbudować.
Nick Wright
Link do artykułu w powyższej odpowiedzi Josha sugeruje użycie systemowej zmiennej środowiskowej do wyłączenia ponownego użycia węzła w Visual Studio i procesie MSBuild (MSBUILDDISABLENODEREUSE = 1) - to zadziałało dla mnie.
Nick Wright,
2

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 :)

chevhfghfghfgh
źródło
Wow, dzięki stary, dokładnie mój problem. Ponieważ pyta mnie o hasło użytkownika podczas uruchamiania exe, po raz pierwszy się nie uruchomił. Kiedy próbuję usunąć tę aplikację z listy procesów, a następnie ponownie debugować, działała bezbłędnie.
Chandraprakash
2

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
Michael Ribbons
źródło
2

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.

Pompair
źródło
2

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)"

wprowadź opis zdjęcia tutaj

Patrick z zespołu NDepend
źródło
2
  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]

Novpiar Effendi
źródło
Dlaczego to było na -2? To również zadziałało dla mnie. To nie ma sensu, ale hej, jeśli to działa, to działa.
Wakka02,
Czy to trwałe rozwiązanie? tj. czy musisz robić te 8 kroków za każdym razem?
Arthur Swails,
vs17 nie ma opcji procesu hostingu
John Demetriou
1

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

despuestambien
źródło
Często pojawia się ten błąd podczas kompilacji dla odziedziczonego projektu z TFS. Myślałem, że to było to! Szukano tego w zainstalowanych programach i dodatkach. Nie można znaleźć tej aplikacji narzędzi elektrycznych. Gdzie to się ukryje?
Taersious
1

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

Uriil
źródło
Tak, poszukajJetBrains.Resharper.TaskRunner.*
Dunc,
1

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ć.

Valamas
źródło
1

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. :)

dgundersen
źródło
1

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.

Alex
źródło
1

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

Ocelot
źródło