Befehlskopie, die beim Erstellen mit Code 4 beendet wurde - Visual Studio-Neustart löst sie

Hin und wieder wird beim Erstellen meiner Lösung hier (mit 7 Projekten) in Visual Studio 2010 Premium ed der gefürchtete Fehler "Befehlskopie mit Code 4 beendet" angezeigt.

Dies liegt daran, dass das Post-Build-Ereignis nicht durchlaufen werden kann.

Hier ist, was das Problem vorübergehend löst

• Manchmal: Ein Neustart von Visual Studio und ich können die Lösung erstellen
• Manchmal: Sowohl ein Neustart von Visual Studio als auch der Dateimanager Ihrer Wahl (Q-Dir 4.37) lösen das Problem.

So sieht das Post-Build-Ereignis aus:

xcopy "$(SolutionDir)Solution Items\References\*.dll" "$(TargetDir)" /Y

Wenn die Befehlskopie mit dem Codefehler [Wert einfügen] beendet wird, liegt dies normalerweise an folgenden Ursachen:

• Lese- / Schreibberechtigungen
• fehlende Dateien
• falsche Verzeichnisse

Allerdings gibt es zu Zeiten, in denen ich die Lösung erstelle, offensichtlich kein Problem.

Zu Ihrer Information, ich habe ReSharper 5.1.1 vor zwei Wochen deinstalliert und Visual Studio hat mir seitdem einige Fehler gemeldet (darunter das Debuggen nicht möglich). Ich habe Visual Studio neu installiert und es funktioniert seitdem besser, bekomme aber immer noch dieses Problem. Könnte es damit zu tun haben, dass einige ReSharper-Sachen irgendwo sind?

Haben Sie das gleiche Problem gehabt und es gelöst? Oder haben Sie eine mögliche Lösung dafür?

Ich habe immer festgestellt, dass dies ein Problem beim Sperren von Dateien ist. Code 4 lautet "Auf Datei kann nicht zugegriffen werden". Eine Teillösung, die ich gefunden habe, ist die Verwendung der Option / C für xcopy (die bei einem Fehler fortgesetzt wird). Nicht wirklich eine Lösung, aber meistens hat es verhindert, dass meine Builds fehlschlagen.

Eine andere Lösung, die nur mit 32-Bit funktioniert, besteht darin, das Windows- Tool zum Entsperren zu verwenden, um die Windows-Handles für die Datei vor dem Kopieren freizugeben.

Bearbeiten: Ich habe gerade festgestellt, dass es auch unter 64 Bit funktioniert.

Während /C Fehler ignorieren kann, ist es vielleicht nicht die wirkliche Lösung sein , da es Dateien sein könnte , die für den Build kopiert , um MÜSSEN werden erfolgreich zu sein.

Das häufigste Problem sind die fehlenden Anführungszeichen um die vordefinierten Befehls-Tags (z. B. $TargetDir). Wenn verschiedene Zweige und Pfade in Code oder TFS erstellt werden, besteht eine sehr hohe Wahrscheinlichkeit, dass dies auftritt.

Wenn die Datei schreibgeschützt ist, kann dies manchmal auch zu Problemen führen. Fügen Sie die /ROption hinzu, mit der schreibgeschützte Dateien kopiert werden können. Eine Liste der verfügbaren Optionen finden Sie unter:

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/xcopy.mspx?mfr=true

Ein weiteres mögliches Problem ist, dass auf den zugrunde liegenden Ordner nicht zugegriffen werden kann. Wenn ja, versuchen Sie "start xcopy"statt "xcopy". Dies öffnet ein weiteres Befehlsfenster, jedoch mit Administratorrechten.

Ich habe den gleichen Fehler gekreuzt, aber es liegt nicht daran, dass die Datei gesperrt ist, aber die Datei fehlt.

Der Grund, warum VS versucht hat, eine nicht vorhandene Datei zu kopieren, ist der Befehl Post-build event.

Nachdem ich das geklärt hatte, war das Problem gelöst.

AKTUALISIEREN:

Wie @rhughes kommentierte:

Das eigentliche Problem ist, wie der Befehl hier funktioniert, anstatt ihn zu entfernen.

und er hat absolut recht.

Ich habe auch dieses Problem konfrontiert. Überprüfen Sie das Ergebnis im Fehlerfenster.

In meinem Fall \stürzte ein Tailing xcopy ab (wie ich es benutzte $(TargetDir)). In meinem Fall $(SolutionDir)..\bin. Wenn Sie einen anderen Ausgang verwenden, muss dieser angepasst werden.

Beachten Sie auch, dass start xcopydies nicht behoben wird, wenn der Fehler nach dem Kompilieren behoben ist. Es wurde möglicherweise nur von der Befehlszeile unterdrückt und es wurde tatsächlich keine Datei kopiert!

Sie können Ihre xcopy-Befehle übrigens manuell in einer Befehlsshell ausführen. Wenn Sie sie dort ausführen, erhalten Sie weitere Details, die Sie in die richtige Richtung weisen.

Wenn das Post-Build-Ereignis den Befehl copy / xcopy zum Kopieren der Build-Ausgabe in ein Verzeichnis enthält (was normalerweise die häufigste Post-Build-Operation ist), kann das Problem auftreten, wenn der vollständige Verzeichnispfad des Quell- oder Zielziels Ordnernamen enthält, die Folgendes enthalten Räume. Entfernen Sie den Speicherplatz für die Verzeichnisnamen und versuchen Sie es.

Wie an vielen Stellen erwähnt, gibt es dafür verschiedene Gründe. Für mich lag es an der Länge von Quelle und Ziel (Pfadlänge). Ich habe xcopy an der Eingabeaufforderung ausprobiert und konnte nicht die vollständige Quelle und den vollständigen Pfad eingeben (nach einigen Zeichen können Sie nicht mehr eingeben). Ich habe dann die Pfadlänge reduziert und konnte rennen. Hoffe das hilft.

Führen Sie VS im Administratormodus aus und es sollte einwandfrei funktionieren.

Ich habe diesen Fehler erhalten, weil das Benutzerkonto, unter dem TFS Build Service ausgeführt wurde, keine Berechtigung zum Schreiben in den Zielordner hatte. Right-click on the folder-->Properties-->Security.

Dies kann in mehreren Fällen passieren:

1. Wenn der vollständige Zeichenfolgenpfad länger als 254 Zeichen ist.
2. Wenn der Name der zu kopierenden Datei falsch ist.
3. Wenn der Zielpfad falsch ist.
4. Wenn das schreibgeschützte Attribut für die kopierte Datei oder den Zielordner festgelegt ist.

Ich habe diesen Fehler erhalten, weil die Datei in einer anderen Instanz geöffnet wurde.

Als ich die Datei schloss und die Lösung erneut erstellte, wurde sie erfolgreich kopiert.

Ich hatte das gleiche Problem bei XCOPY, nachdem der Build abgeschlossen war. In meinem Fall trat das Problem aufgrund von READ-ONLY-Berechtigungen für Ordner auf.

Ich habe den Befehl attrib -R vor XCOPY hinzugefügt und das Problem behoben.

Hoffe es hilft jemandem!

Ich hatte den gleichen Fehler mit xcopy in Verbindung mit der Test Engine. Ich verwende VisualStudio Professional 2013. Standardmäßig scheint Test -> Testeinstellungen -> Testausführungs-Engine laufen zu lassen der Grund für meinen Fehlercode 4 mit xcopy zu sein. Das Ausschalten löste das Problem. Die Ausführungs-Engine scheint einige DLLs zu halten.

Ich hatte das gleiche Problem. Eine einfache 'Clean Solution' in VS löschte den Fehler, war jedoch eine vorübergehende Lösung.

Ich habe festgestellt, dass das Setzen des Parameters "In Ausgabeverzeichnis kopieren" der Datei auf "Immer kopieren" das Sperrproblem behoben zu haben scheint. Obwohl ich jetzt 2 Kopien der Dateien habe und eine löschen muss.

Ich hatte das gleiche Problem. Bei mir hat jedoch nichts funktioniert. Ich habe das Problem durch Hinzufügen gelöst

exit 0

zu meinem Code. Das Problem war, dass beim Kopieren der Dateien manchmal die letzte Datei nicht gefunden wurde und der Schläger einen Wert ungleich Null zurückgab.

Hoffe das hilft jemandem!

Wenn Sie Windows 7 ausführen, können Sie den neuen Befehl 'robocopy' verwenden:

robocopy "$(SolutionDir)Solution Items\References\*.dll" "$(TargetDir)"

Weitere Informationen zur Robokopie finden Sie hier .

Ich stand vor dem gleichen Problem. Ich habe Post-Build-Ereignisse gelöscht und es hat funktioniert. Manchmal, wenn wir einige SQL-Komponenten hinzufügen, werden möglicherweise auch Post-Build-Befehle hinzugefügt.

Ich erhalte etwas Ähnliches mit einer xcopy mit der Option / exclude. In meinem Fall stellte ich fest, dass das Bearbeiten des Post-Build-Ereignisses (etwas harmloses wie eine neue Zeile nach dem Befehl) und das Speichern des Projekts den Fehler verursacht. Durch erneutes Speichern der in der Option / exclude angegebenen Datei funktioniert sie erneut.

Während ich eine DLL-Bibliothek schreibe, habe ich den Befehl xcopy verwendet, um die Bibliothek zu kopieren, in die das Programm sie finden und laden kann. Nach mehrmaligem Öffnen und Schließen des Programms gab es im Taskmanager noch einen offenen Prozess, den ich nicht erkannte.

Suchen Sie nach einem Prozess, von dem aus die Datei verwendet werden kann, und schließen Sie sie.

Was es für mich behoben hat : Suchen Sie nach der spezifischen Lösung für das gewünschte Projekt, dh NICHT nach der Gesamtlösungsdatei für alle Projekte.

Versuchen Sie es - ich habe alles versucht, was hier erwähnt wurde, aber ohne Erfolg.

Ich sehe hier nichts, was darauf hindeutet, dass es sich um eine Web-App handelt, aber ich habe dieses Problem selbst festgestellt. Ich habe zwei xcopy-Befehle für ein Post-Build-Ereignis und nur einer von ihnen ist fehlgeschlagen. Etwas hatte eine Sperre für die Datei und es war nicht Visual Studio (als ich versuchte, es neu zu starten.)

Das einzige andere, was die von mir erstellte DLL verwendet hätte, war IIS. Und siehe da,

Ein einfacher iisresethat den Trick für mich getan.

Ich hatte das gleiche Problem. Dies wurde dadurch verursacht, dass dieselbe Flagge zweimal vorhanden war, zum Beispiel:

if $ (Konfigurationsname) == Release (xcopy "$ (TargetDir) . " "$ (SolutionDir) Bereitstellung \ $ (Projektname) \" / e / d / i / y / e)

Beachten Sie, dass das Flag "/ e" zweimal angezeigt wird. Durch Entfernen des Duplikats wurde das Problem behoben.

In meinem Fall war mein $(OutDir)einfach ..\..\Build\ein relativer Weg. Und als ich versuchte, wie folgt zu xkopieren, bekam xcopy /y "$(OutDir)Proj1.dll" "Anypath\anyfolder\"ich den Exit-Code-Fehler 4.

Was passierte war, dass dieser Befehl im $ (OutDir) (in meinem Fall Build-Ordner) selbst ausgeführt wurde und nicht im Verzeichnis, in dem sich die csproj-Datei des Projekts befand (wie wir es normalerweise erwarten würden). Daher bekam ich immer wieder File not foundFehler (entsprechend Exit-Code 4).

Ich konnte dies nicht herausfinden, bis ich cdin die Post Build-Ereignisse schrieb, um zu drucken, in welchem ​​Verzeichnis dies ausgeführt wurde.

Zusammenfassend lässt sich sagen, dass wir, wenn wir copy/ xcopyfiles from the möchten $(OutDir), entweder verwenden "$(TargetDir)"(dies ist der vollständige Pfad für das Ausgabeverzeichnis) oder überhaupt keinen Pfad angeben müssen.

Kann durch VMWare Workstation mit freigegebenen Ordnern verursacht werden

Ich habe immer das Problem, wenn der Zielordner von xcopyauch als freigegebener Ordner in einer VM zugeordnet ist.

Ich habe es mit einem Skript gelöst, das in der VM ausgeführt wird und den Inhalt des freigegebenen Ordners löscht.

Um auf Rhughes Antwort zu erweitern,

Die Robokopie funktioniert einwandfrei, nur für den Fall, dass Sie Unterverzeichnisse einschließen müssen, mit denen Sie Unterverzeichnisse /eeinschließen und leere Verzeichnisse kopieren können, oder /sum Unterverzeichnisse ohne leere Verzeichnisse einzuschließen .

Außerdem meldet Robocopy einige Dinge zurück, z. B. wenn neue Dateien kopiert wurden. Dies führt dazu, dass sich VS beschwert, da alles über 0 ein Fehler ist und Robocopy 1 zurückgibt, wenn neue Dateien gefunden wurden. Es ist erwähnenswert, dass Robocopy zuerst die Quelle / das Ziel vergleicht und nur die aktualisierten / neuen Dateien kopiert.

Um dies zu umgehen, verwenden Sie:

(robocopy "$(SolutionDir)Solution Items\References\*.dll" "$(TargetDir)") ^& IF %ERRORLEVEL% LEQ 4 exit /B 0

Wenn Sie hier sind, weil Ihr Projekt nicht auf einem Build-Server erstellt werden kann, sondern "manuell" auf einem Entwicklungscomputer einwandfrei erstellt wird und Sie xcopynur zum Debuggen und Emulieren einer Produktionsumgebung auf einem Entwicklungscomputer arbeiten, möchten Sie möglicherweise einen Blick darauf werfen bei dieser Lösung:

https://stackoverflow.com/a/1732478/2279059

Sie deaktivieren einfach Post-Build-Ereignisse auf dem Build-Server mit

msbuild foo.sln /p:PostBuildEvent=

Dies ist nicht gut genug, wenn Sie andere Post-Build-Ereignisse haben, die ebenfalls auf dem Build-Server ausgeführt werden müssen, und es ist keine allgemeine Lösung. Da es jedoch so viele verschiedene Ursachen für dieses Problem gibt, kann es keine allgemeine Lösung geben. Eine der vielen Antworten auf diese Frage (und ihre Duplikate) wird wahrscheinlich helfen, aber seien Sie vorsichtig mit Ansätzen, die die Fehlerbehandlung nur irgendwie umgehen (wie z. B. xcopy /C). Diese funktionieren möglicherweise für Sie, insbesondere auch im Build-Server-Szenario, aber ich denke, dieses ist zuverlässiger, wenn es verwendet werden kann.

Es wurde auch vorgeschlagen, dass das Problem bei neueren Versionen von Visual Studio nicht mehr besteht. Wenn Sie also eine alte Version verwenden, sollten Sie Ihre Build-Tools aktualisieren.

Fehlercode 4 kann viele Dinge bedeuten. Ich empfehle daher, auch die anderen Antworten zu lesen, bis Sie eine für Sie geeignete Lösung gefunden haben UND Sie verstehen, WARUM sie funktioniert (einige Lösungen deaktivieren nur die Fehlerbehandlung, wodurch das Problem möglicherweise nur maskiert wird, nicht jedoch löse es).

Dies kann ein Problem beim Sperren von Dateien im Zusammenhang mit dem parallelen Erstellen sein. Eine Problemumgehung besteht darin, kein paralleles Erstellen zu verwenden. Dies ist das Standardverhalten. Wenn Sie jedoch die -mOption verwenden, werden Projekte parallel erstellt. Die folgenden Variationen sollten keine Projekte parallel erstellen, damit Sie nicht auf das Problem der Dateisperrung stoßen.

msbuild -m:1
msbuild -maxcpucount:1
msbuild

Beachten Sie, dass dies im Gegensatz zu dem, was hier gesagt wurde, sogar mit der "neuesten" Version von MSBuild (aus Build Tools für Visual Studio 2019) geschieht.

Die beste Lösung besteht wahrscheinlich darin, sicherzustellen, dass Sie keine Dateien in einem Post-Build-Schritt kopieren müssen. In einigen Situationen können Sie auch Schritte nach dem Erstellen deaktivieren, wenn Sie mit MSBuild auf einem Erstellungsserver erstellen: https://stackoverflow.com/a/55899347/2279059