Frage

Was bedeutet diese Fehlermeldung? Was könnte ich tun, um dieses Problem zu beheben?

AssemblyInfo.cs mit Code 9009 verlassen


Das Problem ist wahrscheinlich als Teil eines Nachbauerschritts in einer .NET-Lösung in Visual Studio.

Keine korrekte Lösung

Andere Tipps

Haben Sie versucht, den vollständigen Pfad des Befehls zu geben, der im Befehl vor oder nach dem Bau von Ereignissen ausgeführt wird?

Ich bekam den 9009 -Fehler aufgrund von a xcopy Nachbauer-Ereignisbefehl in Visual Studio 2008.

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

Aber in meinem Fall war es auch zeitweise. Das heißt, die Fehlermeldung bleibt bis zum Neustart des Computers und verschwindet nach einem Neustart des Computers. Es ist nach einem remote verwandten Problem zurück, das ich noch nicht entdeckt habe.

In meinem Fall löste die Bereitstellung des Befehls seinen vollständigen Pfad jedoch das Problem:

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

Statt: nur:

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

Wenn ich nicht den vollen Weg habe, läuft es eine Weile nach einem Neustart und stoppt dann.

Auch wie in den Kommentaren zu diesem Beitrag erwähnt, Wenn es Räume gibt In vollem Weg braucht man dann man braucht dann Anführungszeichen um den Befehl. 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 Räume nicht getestet wird.

Fehlercode 9009 bedeutet Fehlerdatei nicht gefunden. Alle in den Antworten hier veröffentlichten Gründe sind eine gute Inspiration, um herauszufinden, warum, aber der Fehler selbst bedeutet einfach einen schlechten Weg.

Dies passiert, wenn Ihnen einige Umgebungseinstellungen für die Verwendung von Microsoft Visual Studio X86 Tools fehlen.
Versuchen Sie daher, in Ihren Nachbuild-Schritten als erster Befehl hinzuzufügen:

Für Visual Studio 2010 Verwendung:

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

Wie @floriankoch in Kommentaren erwähnt, für vs 2017 Verwendung:

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

Es sollte vor einem anderen Befehl platziert werden.
Es wird die Umgebung für die Verwendung von Microsoft Visual Studio X86 -Tools festgelegt.

Höchstwahrscheinlich haben Sie Platz in Ihrem resultierenden Weg.

Sie können dies umgehen, indem Sie die Pfade zitieren und so Räume zulassen. Zum Beispiel:

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

Hatte die gleiche Variable nach der Änderung der Pfadvariablen von Umgebungsvariablen in Win 7. Wechsel zur Standardverwaltung geholfen.

Ich hatte den Fehler 9009, als mein Post -Build -Event -Skript versucht hat, eine Stapeldatei auszuführen, die im angegebenen Pfad nicht vorhanden war.

Ich habe diesen Fehler verursacht, als ich meine Pfadumgebungsvariable reduzierte. Nach der Bearbeitung fügte ich versehentlich hinzu Path= zum Beginn der Pfadfolge. Bei einer solchen fehlförmigen Pfadvariablen konnte ich XCopy in der Befehlszeile (kein Befehl oder keine Datei nicht gefunden) ausführen, und Visual Studio weigerte sich, den Schritt nach dem Bau auszuführen, unter Berufung auf Fehler mit Code 9009.

Xcopy liegt üblicherweise in C: Windows System32. Sobald die Pfadumgebungsvariable es XCOPY ermöglichte, bei der DOS -Eingabeaufforderung behoben zu werden, hat Visual Studio meine Lösung gut erstellt.

Wenn das Skript tatsächlich das tut, was es tun muss, und es nur Visual Studio, die Sie über den Fehler nervt, können Sie nur hinzufügen:

exit 0

bis das Ende von dir Skript.

Prüfe die Rechtschreibung. Ich habe versucht, eine ausführbare Datei anzurufen, hatte aber den Namen falsch geschrieben und es gab mir das exited with code 9009 Botschaft.

In meinem Fall musste ich zuerst "CD" (Änderungsverzeichnis) in das richtige Verzeichnis, bevor ich den Befehl aufrief, da die ausführbare Datei, die ich anrief, in meinem Projektverzeichnis war.

Beispiel:

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

Mein genauer Fehler war

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

9009 bedeutet, dass Datei nicht gefunden wurde, aber tatsächlich den "ISCC" -Teil des Befehls nicht finden konnte.

Ich habe es durch Hinzufügen behoben ";C:\Program Files\Inno Setup 5 (x86)\" zur Systemumgebungsvariable "path"

Eine weitere Variante:

Heute rufe ich Python Interpreter von Cron in Win32 an und nehme ExitCode (%ERRALLEVEL%) 9009, da Systemkonto, das von Cron verwendet wird, keinen Weg zum Python -Verzeichnis hat.

Das Problem in meinem Fall trat auf, als ich versuchte, in meiner Testklassenbibliothek einen Befehl in der Befehlszeile für das Nachbauerereignis zu verwenden. Wenn Sie Anführungszeichen wie SO 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.

Stellen Sie außerdem sicher, dass das Bearbeitungsfenster des Post -Build -Event -Event -Bearbeitungsfensters in Ihrem Projekt keine Zeilenumbrüche gibt. Manchmal wird das Kopieren des XCopy-Befehls aus dem Web, wenn es sich um Multi-Line handelt, und das Einfügen in VS verursacht ein Problem.

Ich habe "> myFile.txt" zum Ende der Zeile im Schritt vor dem Bau hinzugefügt und dann die Datei auf den tatsächlichen Fehler inspiziert.

Die Antwort der TFA wurde heruntergekommen, kann dieses Problem aber tatsächlich verursachen. Dank Hanzolo schaute ich in das Ausgangsfenster und fand Folgendes:

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 Rennen npm install -g gulp, Ich habe aufgehört, diesen Fehler zu bekommen. Wenn Sie diesen Fehler in Visual Studio erhalten, überprüfen Sie das Ausgabefenster und prüfen Sie, ob es sich bei dem Problem um eine nicht festgelegte Umgebungsvariable handelt.

Für mich war der Speicherplatz niedrig und Dateien, die nicht geschrieben werden konnten, sollten später vorhanden sein. Andere Antworten erwähnten fehlende Dateien (oder fehlbezeichnete/falsch referenziert nach Dateien)-aber die Stammursache war der Mangel an Speicherplatz.

Eine weitere Variante der Datei, die aufgrund von Räumen im Pfad nicht gefunden wurde. In meinem Fall im MSBUILD -Skript. Ich musste den HTML -Stil verwenden " Saiten innerhalb des Exec -Befehls.

<!-- 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" />

Gleich wie die anderen Antworten, in meinem Fall lag es an der fehlenden Datei. Um zu wissen, was die fehlende Datei ist, können Sie zum Ausgabefenster gehen und Sie werden Ihnen sofort zeigen, was fehlte.

So öffnen Sie das Ausgangsfenster in Visual Studio:

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

enter image description here

Ich habe dies behoben, indem ich einfach Visual Studio neu gestartet habe - ich hatte gerade gelaufen dotnet tool install xxx In einem Konsolenfenster und VS hatten die neuen Umgebungsvariablen und/oder Pfadeinstellungen, die geändert wurden, noch nicht aufgegriffen, sodass ein schneller Neustart das Problem behoben hatte.

Das ist ziemlich einfach, ich hatte dieses Problem und peinlich einfaches Versagen.

Anwendungsnutzungsbefehlszeilenargumente, ich habe sie entfernt und dann zurückgefügt. Plötzlich konnte das Projekt nicht bauen.

Visual Studio -> Projekteigenschaften -> Überprüfen

Ich habe den Textbereich und post/post-build verwendet, was in diesem Fall falsch war.

Für mich geschah es nach dem Upgrade von Nuget -Paketen von einer Postsharp -Version auf die nächste in einer großen Lösung (~ 80 Projekt). Ich habe Compiler -Fehler für Projekte, die Befehle in Präbuild -Events haben.

'CMD' wird nicht als interner oder externer Befehl, operierbares Programm oder Stapeldatei erkannt. C: Programmdateien (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 "mit Code 9009 beendet.

Die Pfadvariable wurde mit mehreren wiederholten Pfaden, die sich auf Postsharp.Patterns.Diagnostics beziehen, zu lang verfälscht. Als ich Visual Studio schloss und es erneut öffnete, wurde das Problem behoben.

Meine Lösung war einfach einfach wie: Haben Sie versucht, sie wieder auszuschalten? Also habe ich den Computer neu gestartet und das Problem war weg.

Ich bin auch darauf getroffen 9009 Problem bei einer überschreibenden Situation.

Grundsätzlich, wenn die Datei bereits vorhanden ist und Sie die nicht angegeben haben /y Switch (was automatisch überschreibt) Dieser Fehler kann beim Ausführen eines Builds auftreten.

Eigentlich bemerkte ich, dass aus irgendeinem Grund die % der Umweltvariablen von % Windir % manchmal gelöscht wird. Was für mich funktioniert hat, war, die Variable der Windir-Umgebung in C: Windows, neu zu starten vs, und das war's. Auf diese Weise verhindern Sie, dass die Lösungsdateien geändert werden müssen.

Zumindest in Visual Studio Ultimate 2013, Version 12.0.30723.00 Update 3 ist es nicht möglich, eine IF/sonst -Anweisung mit einer Zeilenpause zu trennen:

Werke:

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

funktioniert nicht:

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

Ein weiterer Grund: Wenn Ihr Ereignis vor dem Bau auf einen anderen Projekt-Bin-Pfad verweist und Sie diesen Fehler beim Ausführen von MSBuild, jedoch nicht bei Visual Studio, sehen, müssen Sie die Projekte in der Datei *.ln (mit einem Texteditor) manuell anordnen Das Projekt, auf das Sie im Rahmen des Event -Projekts aufgerufen werden, wird vor dem Projekt erstellt. Mit anderen Worten, MSBuild verwendet die Reihenfolge, dass Projekte in der Datei *.Sln aufgeführt sind, während vs VS Kenntnisse über Projektabhängigkeiten verwendet. Ich hatte dies geschehen, als ein Tool, das eine Datenbank erstellt hat, die in einem WixProj aufgenommen werden soll, nach dem WixProj aufgeführt wurde.

Ich denke, in meinem Fall gab es russische Symbole auf dem Weg (alle Projekte waren im Benutzerordner). Wenn ich eine Lösung in einen anderen Ordner (direkt auf der Festplatte) stecke, wurde alles in Ordnung.

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

Sie müssen sicherstellen, dass Sie Grunzen weltweit installiert haben

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top