Co się dzieje, gdy program Visual Studio wyświetla komunikat „xcopy zakończył działanie z kodem 4”

Nie jestem zaznajomiony z wydarzeniami po kompilacji, więc jestem trochę zdezorientowany, co jest nie tak z moim programem. Podczas kompilacji w programie Visual Studio 2010 otrzymuję:

The command "xcopy C:\Users\Me\Path\Foo.bar\Library\dsoframer.ocx C:\Users\Me\Path\Foo.bar\bin\Debug\ /Y /E /D
xcopy C:\Users\Me\Path\Foo.bar\ApplicationFiles C:\Users\Me\Path\Foo.bar\bin\Debug\ /Y /E /D
xcopy C:\Users\Me\Path\url\ C:\Users\Me\Path\Foo.bar\bin\Debug\ /Y /E /D
rmdir /S /Q C:\Users\Me\Path\Foo.bar\bin\Debug\.gwt-tmp" exited with code 4.    

Mimo tego błędu program wydaje się działać dobrze, ale nie chcę ignorować tego problemu i mam nadzieję, że nic złego się nie stanie. O dziwo, ta linia na początku była tylko pojedynczym poleceniem (pierwsza kopia xcopy), ale gdy kontynuowałem kompilację projektu (naprawianie innych problemów, głównie odniesień), komunikat o błędzie rozszerzał się coraz bardziej. Masz jakiś pomysł, co się dzieje?

Edycja: Oto zdarzenia po kompilacji, które wydają się kończyć niepowodzeniem -

xcopy $(ProjectDir)Library\dsoframer.ocx $(TargetDir) /Y /E /D
xcopy $(ProjectDir)ApplicationFiles $(TargetDir) /Y /E /D
xcopy $(SolutionDir)com.myUrl.gwt\www $(TargetDir) /Y /E /D
rmdir /S /Q $(TargetDir).gwt-tmp

Kod zakończenia Xcopy 4 oznacza „ Wystąpił błąd inicjalizacji. Za mało pamięci lub miejsca na dysku albo wprowadzono nieprawidłową nazwę napędu lub nieprawidłową składnię w wierszu poleceń ”.

Wygląda na to, że program Visual Studio dostarcza nieprawidłowe argumenty do xcopy. Sprawdź polecenie zdarzenia po kompilacji za pośrednictwem Project > Right Click > Properties > Build Events > Post Build Event.

Zwróć uwagę, że jeśli $(ProjectDir)wyrażenia makra lub podobne terminy mają spacje w wynikowych ścieżkach po rozwinięciu, będą musiały zostać umieszczone w cudzysłowach. Na przykład:

xcopy "$(ProjectDir)Library\dsoframer.ocx" "$(TargetDir)" /Y /E /D1

Przełącz zakładkę zegarka na „ouput” ​​i poszukaj polecenia xcopy. Czasami można znaleźć więcej wiadomości (rzeczywiste dane wyjściowe xcopy), które mogą pomóc w rozwiązaniu problemu. Jeśli nie widzisz karty Wyjście, użyj menu Widok-Wyjście, aby ją pokazać.

Oprócz zaakceptowanej odpowiedzi błąd może również wystąpić, gdy folder docelowy jest tylko do odczytu (często w przypadku korzystania z TFS)

Jeśli plik źródłowy nie został znaleziony, xcopy również zwraca kod błędu 4 .

Otrzymałem komunikat o błędzie „ zakończono z kodem 4 ”, gdy polecenie xcopy próbowało zastąpić plik tylko do odczytu. Udało mi się rozwiązać ten problem, dodając / R do polecenia xcopy. Znak / R wskazuje, że pliki tylko do odczytu powinny zostać nadpisane

stare polecenie:

XCOPY /E /Y "$(ProjectDir)source file" "destination"

nowe polecenie

XCOPY /E /Y /R "$(ProjectDir)source file" "destination"

Jak wyjaśniają inne odpowiedzi, kod zakończenia 4 może mieć wiele przyczyn.

Zauważyłem przypadek, w którym otrzymane nazwy ścieżek przekraczały maksymalną dozwoloną długość (tak jak tutaj ).

Zastąpiłem xcopy robocopy dla zdarzenia po kompilacji, którego dotyczy problem; Robocopy wydaje się obsługiwać ścieżki nieco inaczej i był w stanie ukończyć zadanie kopiowania, którego xcopy nie był w stanie obsłużyć.

To znaczy :

Wystąpił błąd inicjalizacji. Za mało pamięci lub miejsca na dysku albo wprowadzono nieprawidłową nazwę napędu lub nieprawidłową składnię w wierszu poleceń.

Więc w zasadzie może to być prawie wszystko, haha ​​... spróbuj uruchomić polecenie pojedynczo z wiersza poleceń, aby dowiedzieć się, która część polecenia sprawia ci kłopoty.

Dostałem to wraz z wiadomością

Nieprawidłowa specyfikacja dysku

podczas kopiowania do udziału sieciowego bez podania nazwy dysku, np

xcopy . \\localhost

gdzie

xcopy . \\localhost\share

był oczekiwany

Natknąłem się na ten problem, więc uruchomiłem polecenie xcopy z wiersza poleceń i powiedziałem:

File creation error - The requested operation cannot be performed on a file with
 a user-mapped section open.

Właściwie to Visual Studio coś trzymało. Właśnie ponownie uruchomiłem Visual Studio i zadziałało.

W moim przypadku problem wynikał z nieprawidłowej kolejności kompilacji. Jeden projekt miał polecenie xcopy na zdarzeniach po kompilacji, aby skopiować pliki z folderu bin do innego folderu. Ale z powodu nieprawidłowych zależności nowe pliki były tworzone w folderze bin, podczas gdy xcopy jest w toku.

W VS kliknij prawym przyciskiem myszy projekt, w którym masz zdarzenia po kompilacji. Przejdź do Build Dependencies> Project Dependencies i upewnij się, że jest poprawna. Sprawdź również kolejność kompilacji projektu (następna karta do zależności).

Ten błąd jest spowodowany tym, że w miejscu kopiowania repozytorium znajdują się białe spacje. Np. Mój projekt jest kopiowany w poniższą lokalizację c://projects/My rest project wtedy widać tam białe spacje, jeśli zmienisz ścieżkę repozytorium na niższą, powinno działać c://projects/myrestproject

Miałem ten sam problem. Możesz też sprawdzić, w którą stronę wskazuje ukośnik. U mnie zadziałało użycie odwrotnego ukośnika zamiast ukośnika. Przykład

xcopy /s /y "C:\SFML\bin\*.dll" "$(OutDir)"

Zamiast:

xcopy /s /y "C:/SFML/bin/*.dll" "$(OutDir)"

Miałem polecenie po kompilacji, które działało dobrze, zanim wykonałem aktualizację w VS 2017. Okazało się, że narzędzia SDK zostały zaktualizowane i znalazły się pod nową ścieżką, więc nie mogłem znaleźć narzędzia, którego używałem do podpisywania moich zestawów.

To się zmieniło od tego ....

call "%VS140COMNTOOLS%vsvars32"
    "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\x64\sn.exe" -Ra "$(TargetPath)" "$(ProjectDir)Key.snk"

Do tego...

"C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\x64\sn.exe" -Ra "$(TargetPath)" "$(ProjectDir)Key.snk"

Bardzo subtelna, ale przełomowa zmiana, więc sprawdź ścieżki po aktualizacji, jeśli widzisz ten błąd.

Inną rzeczą, aby zwrócić uwagę na to podwójne ukośniki, ponieważ xcopynie toleruje je w parametrze toru wejściowego (ale nie tolerować je w ścieżce wyjścia ...).

Jeśli jakiekolwiek inne rozwiązanie jest w trybie debugowania, najpierw zatrzymaj je wszystkie, a następnie uruchom ponownie Visual Studio. U mnie to zadziałało.

Może się to również zdarzyć, jeśli folder docelowy jest używany przez inne procesy . Zamknij wszystkie programy, które mogą korzystać z folderu docelowego i spróbuj.

Możesz użyć monitora zasobów (narzędzia Windows), aby sprawdzić procesy, które używają folderu docelowego.

To zadziałało dla mnie !.