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


292

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.


7
L'OP non tornerà per risolvere questo problema, ma ha molte risposte e molto succo di Google. Quindi, proviamo a dedurre il problema?
Anthony Mastrean,

13
La finestra di output mi ha dato un'idea di questo problema che stavo
riscontrando

Risposte:


241

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.


44
Ho anche ricevuto l'errore 9009 su eventi post e pre-build. Il controllo della scheda Output in Visual Studio mostra il problema. Nel mio caso stavo cercando di accedere a un percorso contenente uno spazio
Phil Hale,

16
Ho avuto un problema simile a questo, ma era il risultato di spazi nei nomi delle cartelle. Mettendo i percorsi tra virgolette ( "$(SolutionDir)packages\NUnit.2.5.10.11092\tools\"nunit-console "$(TargetPath)") risolto.
Justin Morgan,

1
Ho riscontrato un problema simile con un evento pre-build che utilizzava un'applet Java per precompilare JS e CSS ... risulta che avevamo trascurato di mettere Java Runtime sul server.
salse,

2
È possibile che la PATHvariabile d'ambiente si perda in qualche modo? Ottengo questo errore ogni tanto. Ho npm installimpostato un evento pre-build e inizialmente funziona (quindi presumo che tutto sia impostato), ma poi casualmente smetterà di funzionare durante il giorno (generalmente quando si passa da soluzioni / rami credo) e non funzionerà più sapere npm. Il riavvio di VS lo "corregge" ... il che significa che il mio PATHè impostato correttamente, ma sembra alzarsi da VS. Se ci fosse un modo per visualizzare le variabili env dall'interno di VS, potrei confermarlo.
Jamiebarrow,

2
Se vuoi proteggere la tua build dagli arresti anomali in diversi ambienti, diciamo, windows installato su D: \, usa le variabili d'ambiente insieme alla risposta di @thehhv:%systemroot%\System32\xcopy ...
Dorival

110

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.


1
Il mio problema con il file non trovato era il riferimento nel file csproj era $ (PROGRAMFILES) \ Microsoft SDKs \ TypeScript \ tsc e doveva essere $ (PROGRAMFILES) \ Microsoft SDKs \ TypeScript \ 1.0 \
tsc

Grazie per aver effettivamente risposto alla prima domanda.
AntonK,

E significa non trovare alcun file che potrebbe essere coinvolto dal comando tentato, quindi anche quando non è stato possibile trovare il comando stesso. Stavo usando Elimina invece di DEL. Anche questo ti darebbe un 9009.
Mircea Ion,

84

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.


3
Potresti aiutarmi - dove e in quale file devo aggiungere la riga call "$(DevEnvDir)..\Tools\vsvars32.bat"? Grazie
surfmuggle il

2
Ho dovuto aggiungere una voce alla mia Pathvariabile d'ambiente. Controlla la finestra Output per ulteriori informazioni.
paqogomez,

Attenzione. Questo fallirà su molti server di build: blogs.clariusconsulting.net/kzu/devenvdir-considered-harmful
George Mauer

2
Grazie, per x64 bit toolchain ho risolto in questo modo: "$ (DevEnvDir) .. \ VC \ vcvarsall.bat"
codekiddy,

1
Per VS 2017 il file è"$(DevEnvDir)..\Tools\VsDevCmd.bat"
Florian Koch il

57

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

9
+1 - Questo è esattamente il problema che stavo avendo. Un comando nel mio post-build ha funzionato quando ho creato il progetto localmente, ma non è riuscito quando è stato creato sul server di build. Ho appena inserito il comando tra virgolette doppie per risolverlo. Grazie.
Sheikhjabootie,

Quindi è ragionevole ipotizzare che l'errore 9009 sia "file non trovato" ..? Personalmente, penso alla domanda "che cos'è l'errore 9009 di MSBuild?" dovrebbe andare perfettamente bene come domanda autonoma, ma diretto a Microsoft!
The Dag

11

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


10

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.


6

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.


6

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"


5

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.


5
nascondere qualsiasi potenziale errore non dovrebbe essere la strada da percorrere
igelineau

1
Sono d'accordo che questo non dovrebbe essere mascherato
AltF4_11

5

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


1
A questo aggiungi un controllo per l'esistenza dell'eseguibile sul tuo sistema.
Joshua Drake,

5

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"

1
Questo risolto il problema per me che eseguivo devenv.exe di Visual Studio, ma non è necessario specificare la cartella la seconda volta, basta chiamare
build.bat

4

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.


4

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.


4

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.


3

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.


Sebbene jesse abbia ragione nel non avere interruzioni di riga nel mezzo di un comando xcopy, nota che nel caso generale è valido avere interruzioni di riga in questo campo; ogni riga deve essere interpretata come un proprio comando.
RJFalconer,

3

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


2

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.


2

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.


2

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

2

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

inserisci qui la descrizione dell'immagine


2

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.


1

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.


1

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


1

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.


0

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.


0

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)

0

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.


0

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.


0

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.


0

Devi assicurarti di aver installato grunt a livello globale

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.