Che cosa significa "uscito con il codice 9009" durante questa build?

Cosa significa questo messaggio di errore? Cosa potrei fare per correggere questo problema?

AssemblyInfo.cs è uscito con il codice 9009

Il problema si sta probabilmente verificando come parte di un passaggio post-build in una soluzione .NET in Visual Studio.

Hai provato a fornire il percorso completo del comando in esecuzione nel comando di evento pre o post build?

Stavo ottenendo l'errore 9009 a causa di un xcopycomando di evento post-build in Visual Studio 2008.

Il comando è "xcopy.exe /Y C:\projectpath\project.config C:\compilepath\"terminato con il codice 9009.

Ma nel mio caso era anche intermittente. Cioè, il messaggio di errore persiste fino al riavvio del computer e scompare dopo un riavvio del computer. È tornato dopo qualche problema in remoto che devo ancora scoprire.

Tuttavia, nel mio caso, fornire il comando con il suo percorso completo ha risolto il problema:

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

Invece di solo:

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

Se non ho il percorso completo, viene eseguito per un po 'dopo un riavvio, quindi si interrompe.

Inoltre, come menzionato nei commenti a questo post, se ci sono spazi nel percorso completo, allora sono necessarie le virgolette attorno al comando . Per esempio

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

Si noti che questo esempio per quanto riguarda gli spazi non è stato testato.

Il codice di errore 9009 indica che il file di errore non è stato trovato. Tutte le ragioni sottostanti pubblicate nelle risposte qui sono una buona fonte d'ispirazione per capire perché, ma l'errore stesso significa semplicemente un percorso sbagliato.

Succede quando mancano alcune impostazioni di ambiente per l'utilizzo degli strumenti x86 di Microsoft Visual Studio.
Pertanto, prova ad aggiungere come primo comando nei passaggi post-build:

Per Visual Studio 2010 utilizzare:

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

Come @FlorianKoch menzionato nei commenti, per VS 2017 utilizzare:

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

Dovrebbe essere posizionato prima di qualsiasi altro comando.
Imposta l'ambiente per l'utilizzo degli strumenti x86 di Microsoft Visual Studio.

Molto probabilmente hai spazio nel tuo percorso risultante.

Puoi aggirare il problema citando i percorsi, consentendo così gli spazi. Per esempio:

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

Aveva la stessa variabile dopo aver cambiato la variabile PATH da Variabili ambientali in Win 7. Il ritorno al default è stato di aiuto.

Ho avuto l'errore 9009 quando il mio script dell'evento post build stava cercando di eseguire un file batch che non esisteva nel percorso specificato.

Ho causato questo errore quando ho redatto la mia variabile d'ambiente Path. Dopo la modifica, ho aggiunto per errorePath= all'inizio della stringa del percorso. Con una tale variabile di percorso non valida, non sono stato in grado di eseguire XCopy dalla riga di comando (nessun comando o file non trovato) e Visual Studio ha rifiutato di eseguire il passaggio post-build, citando l'errore con il codice 9009.

XCopy risiede comunemente in C: \ Windows \ System32. Una volta che la variabile d'ambiente Path ha permesso a XCopy di essere risolto al prompt di DOS, Visual Studio ha creato bene la mia soluzione.

Il mio errore esatto è stato

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

9009 significa che il file non è stato trovato, ma in realtà non è stato possibile trovare la parte "iscc" del comando.

L'ho risolto aggiungendo ";C:\Program Files\Inno Setup 5 (x86)\"alla variabile di ambiente di sistema"path"

Se lo script fa effettivamente quello che deve fare ed è solo Visual Studio che ti infastidisce per l'errore che potresti semplicemente aggiungere:

exit 0

fino alla fine della tua sceneggiatura.

Controlla l'ortografia. Stavo cercando di chiamare un eseguibile, ma il nome era errato e mi ha dato il exited with code 9009messaggio.

Nel mio caso ho dovuto prima "CD" (Cambia directory) nella directory corretta, prima di chiamare il comando, poiché l'eseguibile che stavo chiamando era nella mia directory di progetto.

Esempio:

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

Un'altra variante:

oggi chiamo interprete python da cron in win32 e prendo ExitCode (% ERRORLEVEL%) 9009, perché l'account di sistema utilizzato da cron non ha percorso nella directory Python.

Il problema nel mio caso si è verificato quando ho provato a utilizzare un comando nella riga di comando per l'evento Post-build nella mia libreria di classi di test. Quando si utilizzano le virgolette in questo modo:

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

o se stai usando la console:

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

Ciò ha risolto il problema per me.

la risposta di tfa è stata declassata, ma in realtà può causare questo problema. Grazie a hanzolo, ho guardato nella finestra di output e ho trovato quanto segue:

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.

Dopo l'esecuzione npm install -g gulp, ho smesso di ottenere questo errore. Se visualizzi questo errore in Visual Studio, controlla la finestra di output e verifica se il problema è una variabile di ambiente non impostata.

Inoltre, assicurati che non ci siano interruzioni di riga nella finestra di modifica degli eventi post build sul tuo progetto. A volte copiare il comando xcopy dal web quando è multilinea e incollarlo in VS causerà un problema.

Ho aggiunto "> myFile.txt" alla fine della riga nella fase di pre-compilazione e quindi ho verificato il file per l'errore effettivo.

Per me, lo spazio su disco era basso e ci si aspettava che i file che non potevano essere scritti fossero presenti in seguito. Altre risposte menzionavano file mancanti (o file erroneamente nominati erroneamente per nome), ma la causa principale era la mancanza di spazio su disco.

Per me è successo dopo aver aggiornato i pacchetti nuget da una versione PostSharp alla successiva in una grande soluzione (progetto ~ 80). Ho errori del compilatore per i progetti che hanno comandi negli eventi PreBuild.

'cmd' non è riconosciuto come comando interno o esterno, programma eseguibile o file batch. C: \ Programmi (x86) \ MSBuild \ 14.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1249,5): errore MSB3073: il comando "cmd / c C: \ GitRepos \ main \ ServiceInterfaces \ DEV.Config \ PreBuild.cmd ServiceInterfaces "è uscito con il codice 9009.

La variabile PATH è stata danneggiata diventando troppo lunga con più percorsi ripetuti relativi a PostSharp.Patterns.Diagnostics. Quando ho chiuso Visual Studio e l'ho riaperto, il problema è stato risolto.

Ancora un'altra variante del file non trovata, a causa degli spazi nel percorso. Nel mio caso nello script msbuild. Avevo bisogno di usare lo stile HTML & quot; stringhe all'interno del comando 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" />

Come le altre risposte, nel mio caso era a causa del file mancante. Per sapere qual è il file mancante, puoi andare alla finestra di output e ti mostrerà subito cosa è scomparso.

Per aprire la finestra di output in Visual Studio:

1. Ctrl + Alt + O
2. Visualizza> Uscita

Ho risolto semplicemente riavviando Visual Studio: ero appena stato eseguito dotnet tool install xxxin una finestra della console e VS non aveva ancora raccolto le nuove variabili di ambiente e / o le impostazioni del percorso che erano state modificate, quindi un riavvio rapido ha risolto il problema.

Questo è piuttosto semplice, ho avuto questo problema e imbarazzante semplice fallimento.

Uso dell'applicazione Argomenti della riga di comando, li ho rimossi e poi li ho aggiunti di nuovo. Improvvisamente il progetto non è stato realizzato.

Visual Studio -> Proprietà del progetto -> verifica di utilizzare la scheda "Debug" (non la scheda "Crea eventi") -> Argomenti della riga di comando

Ho usato l'area di testo e Post / Pre-build, che in questo caso era errata.

La mia soluzione era semplice come: hai provato a spegnerlo e riaccenderlo? Quindi ho riavviato il computer e il problema era scomparso.

Ho anche riscontrato questo 9009problema di fronte a una situazione di sovrascrittura.

Fondamentalmente, se il file esiste già e non hai specificato l' /yopzione (che sovrascrive automaticamente) questo errore può verificarsi quando eseguito da una build.

In realtà ho notato che per qualche motivo la variabile d'ambiente% windir% a volte viene cancellata. Ciò che ha funzionato per me è stato reimpostare la variabile d'ambiente windir su c: \ windows, riavviare VS e il gioco è fatto. In questo modo si evita di dover modificare i file della soluzione.

Almeno in Visual Studio Ultimate 2013, versione 12.0.30723.00 Aggiornamento 3, non è possibile separare un'istruzione if / else con un'interruzione di riga:

lavori:

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

non funziona:

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

Ancora un altro motivo: se l'evento pre-build fa riferimento a un altro percorso bin dei progetti e viene visualizzato questo errore durante l'esecuzione di msbuild, ma non Visual Studio, è necessario disporre manualmente i progetti nel file * .sln (con un editor di testo) in modo che il progetto a cui ti rivolgi nell'evento è stato creato prima del progetto dell'evento. In altre parole, msbuild utilizza l'ordine in cui i progetti sono elencati nel file * .sln mentre VS utilizza la conoscenza delle dipendenze del progetto. Ho avuto questo accadere quando uno strumento che crea un database da includere in un wixproj è stato elencato dopo il wixproj.

Penso che nel mio caso ci fossero simboli russi nel percorso (tutti i progetti erano nella cartella utente). Quando ho messo la soluzione in un'altra cartella (direttamente sul disco), tutto è andato bene.

La mia soluzione era quella di creare una copia del file e aggiungere un passaggio all'attività di compilazione per copiare il mio file sull'originale.

Devi assicurarti di aver installato grunt a livello globale