Was bedeutet "mit Code 9009 beendet" während dieses Builds?

Was bedeutet diese Fehlermeldung? Was kann ich tun, um dieses Problem zu beheben?

AssemblyInfo.cs wurde mit dem Code 9009 beendet

Das Problem tritt wahrscheinlich im Rahmen eines Post-Build-Schritts in einer .NET-Lösung in Visual Studio auf.

Haben Sie versucht, den vollständigen Pfad des Befehls anzugeben, der im Ereignisbefehl vor oder nach dem Build ausgeführt wird?

Ich habe den 9009-Fehler aufgrund eines xcopyEreignisbefehls nach dem Erstellen in Visual Studio 2008 erhalten.

Der Befehl wurde "xcopy.exe /Y C:\projectpath\project.config C:\compilepath\"mit dem Code 9009 beendet.

Aber in meinem Fall war es auch zeitweise. Das heißt, die Fehlermeldung bleibt bis zu einem Neustart des Computers bestehen und verschwindet nach einem Neustart des Computers. Es ist zurück nach einem entfernt verwandten Problem, das ich noch entdecken muss.

In meinem Fall wurde das Problem jedoch behoben, indem der Befehl mit seinem vollständigen Pfad versehen wurde:

c:\windows\system32\xcopy.exe /Y C:\projectpath\project.config C:\compilepath\ 

Anstatt nur:

xcopy.exe /Y C:\projectpath\project.config C:\compilepath\

Wenn ich nicht den vollständigen Pfad habe, wird er nach einem Neustart eine Weile ausgeführt und dann angehalten.

Wie in den Kommentaren zu diesem Beitrag erwähnt, benötigt man Anführungszeichen um den Befehl , wenn Leerzeichen im vollständigen Pfad vorhanden sind . Z.B

"C:\The folder with spaces\ABCDEF\xcopy.exe" /Y C:\projectpath\project.config C:\compilepath\

Beachten Sie, dass dieses Beispiel in Bezug auf Leerzeichen nicht getestet wird.

Fehlercode 9009 bedeutet, dass die Fehlerdatei nicht gefunden wurde. Alle zugrunde liegenden Gründe, die in den Antworten hier aufgeführt sind, sind eine gute Inspiration, um herauszufinden, warum, aber der Fehler selbst bedeutet einfach einen schlechten Weg.

Dies passiert, wenn einige Umgebungseinstellungen für die Verwendung von Microsoft Visual Studio x86-Tools fehlen.
Versuchen Sie daher, als ersten Befehl in Ihren Schritten nach dem Erstellen Folgendes hinzuzufügen:

Verwenden Sie für Visual Studio 2010:

call "$(DevEnvDir)..\Tools\vsvars32.bat"

Wie @FlorianKoch in den Kommentaren erwähnt, verwenden Sie für VS 2017:

call "$(DevEnvDir)..\Tools\VsDevCmd.bat"

Es sollte vor jedem anderen Befehl stehen.
Es wird die Umgebung für die Verwendung von Microsoft Visual Studio x86-Tools festgelegt.

Höchstwahrscheinlich haben Sie Platz in Ihrem resultierenden Pfad.

Sie können dies umgehen, indem Sie die Pfade in Anführungszeichen setzen und so Leerzeichen zulassen. Beispielsweise:

xcopy "$(SolutionDir)\Folder Name\File To Copy.ext" "$(TargetDir)" /R /Y /I

Hatte dieselbe Variable nach dem Ändern der PATH-Variablen von Umgebungsvariablen in Win 7. Das Zurücksetzen auf die Standardeinstellung hat geholfen.

Ich hatte den Fehler 9009, als mein Post-Build-Ereignisskript versuchte, eine Batchdatei auszuführen, die im angegebenen Pfad nicht vorhanden war.

Ich habe diesen Fehler verursacht, als ich meine Umgebungsvariable Path redigiert habe. Nach der Bearbeitung habe ich versehentlich Path=den Anfang der Pfadzeichenfolge hinzugefügt . Mit einer solchen fehlerhaften Pfadvariablen konnte ich XCopy nicht über die Befehlszeile ausführen (kein Befehl oder keine Datei nicht gefunden), und Visual Studio lehnte es ab, den Schritt nach dem Erstellen auszuführen, wobei ein Fehler mit Code 9009 angeführt wurde.

XCopy befindet sich normalerweise in C: \ Windows \ System32. Nachdem die Umgebungsvariable Path die Auflösung von XCopy an der DOS-Eingabeaufforderung ermöglicht hatte, hat Visual Studio meine Lösung gut erstellt.

Mein genauer Fehler war

The command "iscc /DConfigurationName=Debug "C:\Projects\Blahblahblah\setup.iss"" exited with code 9009.

9009 bedeutet, dass die Datei nicht gefunden wurde, der "iscc" -Teil des Befehls jedoch nicht gefunden werden konnte.

Ich habe es behoben, indem ich es ";C:\Program Files\Inno Setup 5 (x86)\"der Systemumgebungsvariablen hinzugefügt habe"path"

Wenn das Skript tatsächlich das tut, was es tun muss, und Visual Studio Sie nur wegen des Fehlers nervt, können Sie einfach Folgendes hinzufügen:

exit 0

bis zum Ende Ihres Skripts.

Prüfe die Rechtschreibung. Ich habe versucht, eine ausführbare Datei aufzurufen, aber der Name war falsch geschrieben und es gab mir die exited with code 9009Nachricht.

In meinem Fall musste ich zuerst "CD" (Change Directory) in das richtige Verzeichnis, bevor ich den Befehl aufrief, da sich die von mir aufgerufene ausführbare Datei in meinem Projektverzeichnis befand.

Beispiel:

cd "$(SolutionDir)"
call "$(SolutionDir)build.bat"

Eine andere Variante:

Heute rufe ich den Python-Interpreter von cron in win32 auf und nehme ExitCode (% ERRORLEVEL%) 9009, weil das von cron verwendete Systemkonto keinen Pfad zum Python-Verzeichnis hat.

Das Problem in meinem Fall trat auf, als ich versuchte, einen Befehl in der Befehlszeile für das Post-Build-Ereignis in meiner Testklassenbibliothek zu verwenden. Wenn Sie solche Anführungszeichen verwenden:

"$(SolutionDir)\packages\NUnit.Runners.2.6.2\tools\nunit" "$(TargetPath)" 

oder wenn Sie die Konsole verwenden:

"$(SolutionDir)\packages\NUnit.Runners.2.6.2\tools\nunit-console" "$(TargetPath)"

Dies hat das Problem für mich behoben.

Die Antwort von tfa wurde abgelehnt, kann aber tatsächlich dieses Problem verursachen. Dank hanzolo habe ich in das Ausgabefenster geschaut und Folgendes festgestellt:

3>'gulp' is not recognized as an internal or external command,
3>operable program or batch file.
3>D:\dev\<filepath>\Web.csproj(4,5): error MSB3073: The command "gulp clean" exited with code 9009.

Nach dem Ausführen npm install -g gulpwurde dieser Fehler nicht mehr angezeigt. Wenn dieser Fehler in Visual Studio auftritt, überprüfen Sie das Ausgabefenster und prüfen Sie, ob das Problem eine nicht festgelegte Umgebungsvariable ist.

Stellen Sie außerdem sicher, dass das Bearbeitungsfenster für Ereignisse nach dem Erstellen Ihres Projekts keine Zeilenumbrüche enthält. Manchmal verursacht das Kopieren des Befehls xcopy aus dem Web, wenn er mehrzeilig ist, und das Einfügen in VS ein Problem.

Ich habe im Vorerstellungsschritt am Ende der Zeile "> myFile.txt" hinzugefügt und dann die Datei auf den tatsächlichen Fehler überprüft.

Für mich war der Speicherplatz gering, und Dateien, die nicht geschrieben werden konnten, sollten später vorhanden sein. Andere Antworten erwähnten fehlende Dateien (oder falsch benannte / falsch referenzierte Dateien mit Namen) - aber die Hauptursache war mangelnder Speicherplatz.

Für mich geschah dies nach dem Upgrade von Nuget-Paketen von einer PostSharp-Version auf die nächste in einer großen Lösung (~ 80-Projekt). Ich habe Compilerfehler für Projekte, die Befehle in PreBuild-Ereignissen haben.

'cmd' wird nicht als interner oder externer Befehl, bedienbares Programm oder Batchdatei erkannt. C: \ Programme (x86) \ MSBuild \ 14.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1249,5): Fehler MSB3073: Der Befehl "cmd / c C: \ GitRepos \ main \ ServiceInterfaces \ DEV.Config \ PreBuild.cmd ServiceInterfaces "wurde mit dem Code 9009 beendet.

Die Variable PATH wurde beschädigt und wurde zu lang, da sich mehrere Pfade auf PostSharp.Patterns.Diagnostics bezogen. Als ich Visual Studio schloss und wieder öffnete, wurde das Problem behoben.

Eine weitere Variante der Datei wurde aufgrund von Leerzeichen im Pfad nicht gefunden. In meinem Fall im msbuild-Skript. Ich musste den HTML-Stil & quot; Zeichenfolgen innerhalb des Befehls exec.

<!-- Needs quotes example with my Buildscript.msbuild file --> 
<Exec Command="&quot;$(MSBuildThisFileDirectory)\wix\wixscript.bat&quot; $(VersionNumber) $(VersionNumberShort)" 
    ContinueOnError="false" 
    IgnoreExitCode="false" 
    WorkingDirectory="$(MSBuildProjectDirectory)\wix" />

Wie bei den anderen Antworten lag es in meinem Fall an der fehlenden Datei. Um zu wissen, was die fehlende Datei ist, können Sie zum Ausgabefenster gehen und es zeigt Ihnen sofort, was fehlte.

So öffnen Sie das Ausgabefenster in Visual Studio:

1. Strg + Alt + O.
2. Ansicht> Ausgabe

Ich habe dies behoben, indem ich Visual Studio einfach neu gestartet habe. Ich habe gerade dotnet tool install xxxin einem Konsolenfenster ausgeführt und VS hat die neuen Umgebungsvariablen und / oder Pfadeinstellungen, die geändert wurden, noch nicht übernommen. Ein schneller Neustart hat das Problem behoben.

Das ist ziemlich einfach, ich hatte dieses Problem und peinliche einfache Fehler.

Anwendung verwenden Befehlszeilenargumente, ich habe sie entfernt und dann wieder hinzugefügt. Plötzlich konnte das Projekt nicht mehr erstellt werden.

Visual Studio -> Projekteigenschaften -> Vergewissern Sie sich, dass Sie die Registerkarte "Debug" (nicht die Registerkarte "Build Events") verwenden -> Befehlszeilenargumente

Ich habe den Textbereich und Post / Pre-Build verwendet, was in diesem Fall falsch war.

Meine Lösung war einfach: Haben Sie versucht, sie aus- und wieder einzuschalten? Also habe ich den Computer neu gestartet und das Problem war behoben.

Ich bin auch auf dieses 9009Problem gestoßen, als ich mit einer Überschreibsituation konfrontiert war.

Grundsätzlich /ykann dieser Fehler auftreten , wenn die Datei bereits vorhanden ist und Sie den Schalter nicht angegeben haben (der automatisch überschreibt), wenn er von einem Build ausgeführt wird.

Eigentlich ist mir aufgefallen, dass aus irgendeinem Grund die Umgebungsvariable% windir% manchmal gelöscht wird. Was für mich funktioniert hat, war, die Windir-Umgebungsvariable auf c: \ windows zurückzusetzen, VS neu zu starten und fertig. Auf diese Weise müssen Sie die Lösungsdateien nicht ändern.

Zumindest in Visual Studio Ultimate 2013, Version 12.0.30723.00 Update 3, ist es nicht möglich, eine if / else-Anweisung durch einen Zeilenumbruch zu trennen:

funktioniert:

if '$(BuildingInsideVisualStudio)' == 'true' (echo local) else (echo server)

funktioniert nicht:

if '$(BuildingInsideVisualStudio)' == 'true' (echo local) 
else (echo server)

Noch ein Grund: Wenn Ihr Pre-Build-Ereignis auf einen anderen Projekt-Bin-Pfad verweist und Sie diesen Fehler sehen, wenn Sie msbuild ausführen, aber nicht Visual Studio, müssen Sie die Projekte in der * .sln-Datei (mit einem Texteditor) manuell anordnen dass das Projekt, auf das Sie im Ereignis abzielen, vor dem Projekt des Ereignisses erstellt wird. Mit anderen Worten, msbuild verwendet die Reihenfolge, in der Projekte in der * .sln-Datei aufgeführt sind, während VS das Wissen über Projektabhängigkeiten verwendet. Ich hatte dies, als ein Tool, das eine Datenbank erstellt, die in ein wixproj aufgenommen werden soll, nach dem wixproj aufgelistet wurde.

Ich denke in meinem Fall waren russische Symbole im Pfad (alle Projekte befanden sich im Benutzerordner). Als ich die Lösung in einen anderen Ordner legte (direkt auf die Festplatte), wurde alles in Ordnung.

Meine Lösung bestand darin, eine Kopie der Datei zu erstellen und der Erstellungsaufgabe einen Schritt hinzuzufügen, um meine Datei über das Original zu kopieren.

Sie müssen sicherstellen, dass Sie grunt global installiert haben