2008-11-21 15 views
93

ich ein Projekt mit einem Beitrag Buildereignis haben:Beitrag Bau beendet mit Code 1

copy $(ProjectDir)DbVerse\Lunaverse.DbVerse.*.exe $(TargetDir) 

Es funktioniert gut, jedes Mal auf meiner Maschine. Ich habe einen neuen Entwickler, der immer den Fehler "mit Code 1 beendet" erhält. Ich ließ sie den gleichen Befehl in einer DOS-Eingabeaufforderung ausführen, und es funktionierte gut. Was könnte das verursachen? Gibt es eine Möglichkeit, zum eigentlichen Fehler zu kommen?

Wir verwenden Visual Studio 2008

+0

in meinem Fall die Antwort Tim Scott am Ende dieser Seite zur Verfügung stellen (so dass ich am Anfang übersehen) mein Problem zu lösen. –

Antwort

102

Sie hatte einen Platz in einem der Ordner Namen in ihrem Weg, und keine Anführungszeichen um ihn herum.

+12

Anführungszeichen auf Pfadnamen ist eine gute Übung. funktioniert nicht in Pfaden, die Platz enthält, ist Ereignis besser :-) – Asher

+0

Die Leerzeichen-Sache hat mich auch. –

+4

copy/y "$ (TargetDir) Dotfuscated \" "$ (TargetDir)" dieser Befehl funktioniert nicht für mich und wenn ich schreibe exit 0 am Ende dann funktioniert gut. Kannst du mir sagen warum? –

11

Get process monitor from SysInternals setzen sie sich für die Lunaverse.DbVerse (auf dem Feld Pfad) auf dem Operationsergebnis aussehen zu beobachten. Es sollte offensichtlich sein, von dort, was schief gelaufen ist

2

Als eine gute Praxis schlage ich vor, Sie ersetzen das Nachbauereignis mit einem MS Build File Copy task.

+1

Was sind die Vorteile von einem gegenüber dem anderen? – GregC

52

Der mit dem „Pings“ hat mir geholfen ... aber vielleicht ein wenig besser ...

die Lösung für mich erklären sollte sich ändern:

copy $(TargetDir)$(TargetName).* $(SolutionDir)bin 

dazu:

copy "$(TargetDir)$(TargetName).*" "$(SolutionDir)bin" 

Ich hoffe, es funktioniert für Sie. :-)

+2

+1 Danke für die Buchung Code! – Dragn1821

+0

+1 Das ist gut – David

41

Mein Grund für den Code 1 war, dass der Zielordner nur gelesen wurde. Hoffe das hilft jemandem! Ich hatte ein Post-Build-Ereignis, um eine Kopie von einem Verzeichnis zu einem anderen zu machen, und das Ziel wurde nur gelesen. Also habe ich einfach das schreibgeschützte Attribut für das Verzeichnis und alle Unterverzeichnisse deaktiviert! Stellen Sie sicher, dass es ein Verzeichnis ist, das sicher ist!

+0

Sparte mir eine Stunde, danke! Heruntergeladenen Code aus dem Internet und Windows 7 setzt den Ordner automatisch auf schreibgeschützt. –

+1

Ich habe auch xcopy statt und mit dem/y-Flag verwendet. Alle Befehle http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/xcopy.mspx?mfr=true –

2

Für mich musste ich sicherstellen, dass das Programm, mit dem ich fertig war, zu der Zeit nicht ausgeführt wurde. Es gab keine Fehler in der Syntax. Hoffe, das hilft jemandem.

6

Ich hatte VS als Administrator ausführen meine Post-Build-Kopie auf einem OS zu erhalten geschützt „.. \ Common7 \ IDE \ Private“

35

zu arbeiten Ich habe dies für zukünftige Besucher hinzugefügt, da diese recht ist eine aktive Frage.

ROBOCOPY verlässt mit „Erfolgscodes“, die unter 8. Siehe sind: http://support.microsoft.com/kb/954404

Das bedeutet:

robocopy exit code 0 = no files copied 
robocopy exit code 1 = files copied 
When the result is 1, this becomes an error exit code in visual studio. 

Also ich durch das Hinzufügen dieser auf den Boden dieses leicht von der gelöst Batch-Datei

exit 0 

vorschlagen, dass behandeln ROBOCOPY Fehler auf diese Weise

rem each robocopy statement and then underneath have the error check. 
if %ERRORLEVEL% GEQ 8 goto failed 

rem end of batch file 
GOTO success 

:failed 
rem do not pause as it will pause msbuild. 
exit 1 

:success 
exit 0  

Verwirrung gesetzt in, wenn keine Dateien kopiert werden = kein Fehler in VS.Dann, wenn es Änderungen gibt, werden Dateien kopiert, VS-Fehler, aber alles, was der Entwickler wollte, wurde gemacht.

Zusätzlicher Tipp: Verwenden Sie keine Pause im Skript, da dies zu einer unbestimmten Pause im VS-Build führen würde. Verwenden Sie während der Entwicklung des Skripts etwas wie timeout 10. Sie werden dies bemerken und es kommentieren, anstatt einen hängenden Build zu haben.

+1

Genau das, was ich gesucht habe. Vielen Dank!! – Ricky

2

Ich habe gerade den gleichen Fehler erhalten. Ich hatte eine% im Zielpfad, der

c:\projects\%NotAnEnvironmentVariable% 

benötigt entkam werden musste

c:\projects\%%NotAnEnvironmentVariable%% 
5

Für diejenigen sein, die sich 'Kopie' Befehl in Buildereignisse (Pre- verwenden Build-Ereignis Befehlszeile oder/und Post-Build-Ereignis Befehlszeile) von Projekt -> Eigenschaften: Sie 'Kopie 'Befehlsparameter sollten hier aussehen: copy "source of files" "destination for files". Denken Sie daran, Anführungszeichen zu verwenden (um Probleme mit Leerzeichen in Adressfolgen zu vermeiden).

0

So viele Lösungen ...

In meinem Fall hatte ich die bat-Datei mit Nicht-Unicode (West, Windows) Codierung zu speichern. Standardmäßig, wenn ich die Datei zu Visual Studio hinzugefügt habe (und wahrscheinlich hätte ich es außerhalb des VS getan haben), fügte es mit UTF-8-Codierung hinzu.

2

Ich konnte meinen Code 1 beheben, indem ich Visual Studio als Admin ausführte. Anscheinend hatte es keinen Zugriff, um die Shell-Befehle ohne Admin auszuführen.

2

Ok, das ist ein Problem mit vielen Lösungen, also poste ich nur meine, um den Leuten mehr Hinweise zu geben. Meine Situation besteht darin, die Ordner in Ihrem Pfad zu überprüfen und sicherzustellen, dass alle auf Ihrem Computer vorhanden sind. Zum Beispiel: "$ (SolutionDir) \ partBin \ Bin \ $ (Projektname) .pdb", aber "Bin" befindet sich nicht im Ordner "partBin".

0

Ich hatte das gleiche Problem und es stellte sich heraus, dass es war, weil ich das Projekt umbenannt hatte. Ich ging in die Projekteigenschaften und änderte den Namen der Assembly und den Root-Namespace in den Projektnamen und es funktionierte großartig danach!

1

Für diejenigen, die ‚Kopie‘ Befehl in Build Event (Pre-Build-Ereignis der Befehlszeile oder/und Postbuildereignis Befehlszeile) aus dem Projekt verwenden -> Eigenschaften: Zielordner sollten

3

existieren hatte ich eine ähnliches Problem, aber speziell in einer Jenkins Build-Umgebung. Um das Problem zu beheben, wechselte ich von der Verwendung eines Kopierbefehls im Postbuildereignis zur Verwendung eines Kopierziels.

ich änderte sich dies:

<PropertyGroup> 
     <PostBuildEvent>copy $(ProjectDir)bin\BLAH.Common.xml $(ProjectDir)App_Data\BLAH.Common.xml</PostBuildEvent> 
    </PropertyGroup> 

dazu:

<Target Name="AfterBuild"> 
    <Copy SourceFiles="$(ProjectDir)bin\BLAH.Common.xml" DestinationFolder="$(ProjectDir)App_Data\" /> 
    </Target> 

und es funktioniert jetzt.

Der genaue Fehler war ich immer war:

(PostBuildEvent target) -> 
    C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(4291,5): error MSB3073: The command "copy <http://1.2.3.4/job/BLAHv2/ws/Api/bin/BLAH.Common.xml> <http://1.2.3.4/job/BLAHv2/ws/Api/App_Data/BLAH.Common.xml"> exited with code 1. [<http://1.2.3.4/job/BLAHv2/ws/Api/Api.csproj]> 
+0

Wie haben Sie diese Änderung vorgenommen? Hast du das manuell bearbeitet? Wie führst du das Ziel aus? Das sieht aus wie etwas, das Sie in der Msbuild-Befehlszeile angeben müssten. Ich habe genau das gleiche Problem in meiner Jenkins-Umgebung, die seltsam ist, weil alle von Msbuild erstellten Ordner immer schreibgeschützt sind. Warum es auf meinem Rechner gut kopiert, aber nicht auf dem Server, ist mir ein Rätsel. – shawn1874

+0

Ich habe gerade Notepad ++ verwendet, um die csproj-Datei zu bearbeiten. Der "AfterBuild" -Hook ist ein Standard-Hook. Wenn er vorhanden ist, wird er nach dem Build-Prozess automatisch aufgerufen. – TechSavvySam

+0

Danke. Ich war mir nicht sicher, ob Sie eine benutzerdefinierte Msbuild-Datei mit einem Ziel hatten oder ob es sich nur um die im Visual Studio erstellte Datei handelte. Zu Ihrer Information: In meinem Fall habe ich herausgefunden, dass das Problem mit der Build-Reihenfolge zu tun hat. Ich habe vergessen, die Build-Abhängigkeiten in der Release-Solution-Konfiguration so zu setzen, dass die Projekte auf dem Server in einer anderen Reihenfolge erstellt wurden, so dass die Eingabedatei beim Ausführen der Kopie noch nicht verfügbar war. Stellen Sie sicher, dass die DLL erstellt wurde, bevor das andere Projekt es für mich reparierte. Das war ein sehr subtiles Problem mit der Lösungskonfiguration, die es verursachte. – shawn1874

Verwandte Themen