Cosa significa “terminato con il codice 9009” durante questa build?

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

AssemblyInfo.cs è terminato con il codice 9009


Il problema sta probabilmente accadendo come parte di un passo 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 ricevendo l’errore 9009 a causa di un comando di evento post-build di xcopy in Visual Studio 2008.

Il comando "xcopy.exe /YC:\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 il riavvio del computer. È tornato dopo un problema 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 /YC:\projectpath\project.config C:\compilepath\ 

Invece di solo:

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

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

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

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

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

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

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

Dovrebbe essere posizionato prima di ogni altro comando.
Imposta l’ambiente per l’utilizzo degli strumenti x86 di Microsoft Visual Studio 2010.

Codice errore 9009 indica che il file di errore non è stato trovato. Tutti i motivi sottostanti inseriti nelle risposte qui sono una buona fonte d’ispirazione per capire perché, ma l’errore stesso indica semplicemente un percorso sbagliato.

Molto probabilmente hai spazio nel tuo percorso risultante.

Puoi aggirare il problema citando i percorsi, consentendo quindi 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. Cambiando di nuovo a predefinito aiutato.

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

Se lo script fa effettivamente ciò che deve fare ed è solo Visual Studio a scoprire l’errore che potresti semplicemente aggiungere:

 exit 0 

alla fine del tuo copione

Ho causato questo errore quando ho cancellato la mia variabile di ambiente Path. Dopo la modifica, ho accidentalmente aggiunto Path= all’inizio della stringa del percorso. Con una variabile del percorso di questo tipo, non ero in grado di eseguire XCopy sulla riga di comando (nessun comando o file non trovato) e Visual Studio ha rifiutato di eseguire il passaggio post-build, citando un errore con il codice 9009.

XCopy risiede comunemente in C: \ Windows \ System32. Una volta che la variabile di ambiente Path consentiva a XCopy di essere risolta al prompt di DOS, Visual Studio ha costruito bene la mia soluzione.

Controlla l’ortografia. Stavo cercando di chiamare un eseguibile ma ho sbagliato il nome e mi ha dato l’ exited with code 9009 messaggio exited with code 9009 .

Il mio errore esatto era

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 in grado di trovare la parte “iscc” del comando.

Ho risolto il problema aggiungendo ";C:\Program Files\Inno Setup 5 (x86)\" alla variabile di ambiente di sistema "path"

Un’altra variante:

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

Nel mio caso ho dovuto prima “CD” (Cambia directory) alla 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" 

Il problema nel mio caso si è verificato quando ho provato a utilizzare un comando sulla riga di comando per l’evento Post-build nella mia libreria di classi di test. Quando usi 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)" 

Questo ha risolto il problema per me.

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

Ho aggiunto “> myFile.txt” alla fine della riga nella fase di pre-costruzione e poi ho ispezionato 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 hanno menzionato i file mancanti (o i nomi erroneamente indicati / non correttamente referenziati), ma la causa principale era la mancanza di spazio su disco.

Ancora un’altra variante di 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.

   

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

Uso dell’applicazione Argomenti della riga di comando, li ho rimossi e quindi aggiunti nuovamente. All’improvviso il progetto non è riuscito a build.

Visual Studio -> Proprietà 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 era sbagliato in questo caso.

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

‘cmd’ non viene 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 “terminato con il codice 9009.

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

la risposta di tfa è stata downvoted, ma in realtà può causare questo problema. Grazie ad hanzolo, ho cercato 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\\Web.csproj(4,5): error MSB3073: The command "gulp clean" exited with code 9009. 

Dopo aver eseguito npm install -g gulp , ho smesso di ricevere questo errore. Se ricevi questo errore in Visual Studio, controlla la finestra di output e verifica se il problema è una variabile di ambiente non impostata.

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

Almeno in Visual Studio Ultimate 2013, Versione 12.0.30723.00 Update 3, non è ansible 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) 

Un altro motivo: se l’evento di pre-build fa riferimento a un altro percorso bin di progetto e viene visualizzato questo errore durante l’esecuzione di msbuild, ma non di Visual Studio, è necessario organizzare manualmente i progetti nel file * .sln (con un editor di testo) in modo che il progetto che stai prendendo di mira nell’evento è costruito 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. Ciò è avvenuto 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 è diventato ok.

La mia soluzione era semplice: hai provato a spegnerlo e riaccenderlo? Così ho riavviato il computer e il problema era sparito.

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

Per aprire la finestra di output in Visual Studio:

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

inserisci la descrizione dell'immagine qui

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

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

In sostanza, se il file esiste già e non è stato specificato l’opzione /y (che sovrascrive automaticamente), questo errore può verificarsi quando viene eseguito da una build.

È necessario assicurarsi di aver installato grunt a livello globale