¿Qué significa "salió con el código 9009" durante esta compilación?

que significa este mensaje de error? ¿Qué podría hacer para corregir este problema?

AssemblyInfo.cs salió con el código 9009

El problema probablemente esté sucediendo como parte de un paso posterior a la compilación en una solución .NET en Visual Studio.

¿Intentó dar la ruta completa del comando que se ejecuta en el comando de evento previo o posterior a la compilación?

Recibí el error 9009 debido a un xcopycomando de evento posterior a la compilación en Visual Studio 2008.

El comando "xcopy.exe /Y C:\projectpath\project.config C:\compilepath\"salió con el código 9009.

Pero en mi caso también fue intermitente. Es decir, el mensaje de error persiste hasta que se reinicia la computadora y desaparece después de un reinicio de la computadora. Está de vuelta después de algún problema relacionado de forma remota que aún no he descubierto.

Sin embargo, en mi caso, proporcionar el comando con su ruta completa resolvió el problema:

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

En lugar de solo:

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

Si no tengo la ruta completa, se ejecuta durante un tiempo después de un reinicio y luego se detiene.

Además, como se menciona en los comentarios a esta publicación, si hay espacios en la ruta completa, entonces se necesitan comillas alrededor del comando . P.ej

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

Tenga en cuenta que este ejemplo con respecto a los espacios no se prueba.

El código de error 9009 significa que no se encontró el archivo de error. Todas las razones subyacentes publicadas en las respuestas aquí son una buena inspiración para descubrir por qué, pero el error en sí mismo simplemente significa un mal camino.

Ocurre cuando faltan algunas configuraciones de entorno para usar las herramientas de Microsoft Visual Studio x86.
Por lo tanto, intente agregar como primer comando en los pasos posteriores a la compilación:

Para uso de Visual Studio 2010:

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

Como @FlorianKoch mencionó en los comentarios, para VS 2017 use:

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

Debe colocarse antes que cualquier otro comando.
Establecerá el entorno para usar las herramientas de Microsoft Visual Studio x86.

Lo más probable es que tenga espacio en su camino resultante.

Puede solucionar esto citando los caminos, permitiendo así espacios. Por ejemplo:

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

Tenía la misma variable después de cambiar la variable PATH de Variables ambientales en Win 7. Cambiar de nuevo a predeterminado ayudó.

He tenido el error 9009 cuando mi script de evento posterior a la compilación intentaba ejecutar un archivo por lotes que no existía en la ruta especificada.

Causé este error cuando redacté mi variable de entorno Path. Después de editar, agregué accidentalmente Path=al comienzo de la cadena de ruta. Con una variable de ruta con este formato incorrecto, no pude ejecutar XCopy en la línea de comando (no se encontró ningún comando o archivo), y Visual Studio se negó a ejecutar el paso posterior a la compilación, citando el error con el código 9009.

XCopy comúnmente reside en C: \ Windows \ System32. Una vez que la variable de entorno Path permitió que XCopy se resolviera en el indicador de DOS, Visual Studio creó bien mi solución.

Mi error exacto fue

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

9009 significa archivo no encontrado, pero en realidad no pudo encontrar la parte "iscc" del comando.

Lo arreglé agregando ";C:\Program Files\Inno Setup 5 (x86)\"a la variable de entorno del sistema"path"

Si el script realmente hace lo que tiene que hacer y solo Visual Studio te está molestando sobre el error, simplemente puedes agregar:

exit 0

hasta el final de tu guión.

Revisar la ortografía. Estaba tratando de llamar a un ejecutable pero tenía el nombre mal escrito y me dio el exited with code 9009mensaje.

En mi caso, primero tenía que "CD" (Cambiar directorio) al directorio apropiado, antes de llamar al comando, ya que el ejecutable al que estaba llamando estaba en el directorio de mi proyecto.

Ejemplo:

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

Otra variante:

hoy llamo al intérprete de python desde cron en win32 y tomo ExitCode (% ERRORLEVEL%) 9009, porque la cuenta del sistema utilizada por cron no tiene ruta al directorio de Python.

El problema en mi caso ocurrió cuando intenté usar un comando en la línea de comandos para el evento Post-build en mi Biblioteca de clase de prueba. Cuando usa comillas así:

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

o si estás usando la consola:

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

Esto solucionó el problema para mí.

La respuesta de tfa ha sido rechazada, pero en realidad puede causar este problema. Gracias a Hanzolo, busqué en la ventana de resultados y encontré lo siguiente:

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.

Después de ejecutar npm install -g gulp, dejé de recibir este error. Si obtiene este error en Visual Studio, verifique la ventana de salida y vea si el problema es una variable de entorno no establecida.

Además, asegúrese de que no haya saltos de línea en la ventana de edición del evento posterior a la compilación en su proyecto. A veces, copiar el comando xcopy de la web cuando es de varias líneas y pegarlo en VS causará un problema.

Agregué "> myFile.txt" al final de la línea en el paso previo a la compilación y luego inspeccioné el archivo para detectar el error real.

Para mí, el espacio en disco era bajo y se esperaba que los archivos que no podían escribirse estuvieran presentes más tarde. Otras respuestas mencionaron archivos faltantes (o archivos mal nombrados / referenciados incorrectamente por nombre), pero la causa raíz fue la falta de espacio en disco.

Para mí sucedió después de actualizar los paquetes nuget de una versión de PostSharp a la siguiente en una gran solución (proyecto ~ 80). Tengo errores de compilación para proyectos que tienen comandos en eventos PreBuild.

'cmd' no se reconoce como un comando interno o externo, programa operativo o archivo por lotes. C: \ Archivos de programa (x86) \ MSBuild \ 14.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1249,5): error MSB3073: El comando "cmd / c C: \ GitRepos \ main \ ServiceInterfaces \ DEV.Config \ PreBuild.cmd ServiceInterfaces "salió con el código 9009.

La variable PATH se corrompió y se hizo demasiado larga con múltiples rutas repetidas relacionadas con PostSharp.Patterns.Diagnostics. Cuando cerré Visual Studio y lo abrí de nuevo, se solucionó el problema.

Otra variante de archivo no encontrada, debido a los espacios en la ruta. En mi caso en el script msbuild. Necesitaba usar el estilo HTML & quot; cadenas dentro 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" />

Igual que las otras respuestas, en mi caso fue por el archivo faltante. Para saber cuál es el archivo que falta, puede ir a la ventana de salida y le mostrará de inmediato lo que se perdió.

Para abrir la ventana de salida en Visual Studio:

1. Ctrl + Alt + O
2. Ver> Salida

Solucioné esto simplemente reiniciando Visual Studio: acababa de ejecutar dotnet tool install xxxen una ventana de consola y VS aún no había recogido las nuevas variables de entorno y / o la configuración de ruta que se modificaron, por lo que un reinicio rápido solucionó el problema.

Esto es bastante básico, tuve este problema, y ​​un simple error vergonzoso.

Uso de la aplicación Argumentos de línea de comando, los eliminé y luego los volví a agregar. De repente, el proyecto no se pudo construir.

Visual Studio -> Propiedades del proyecto -> verifique que use la pestaña 'Depurar' (no la pestaña 'Crear eventos') -> Argumentos de línea de comandos

Utilicé el área de texto y Publicar / Precompilación, que estaba mal en este caso.

Mi solución fue sencilla: ¿has intentado apagarlo y volver a encenderlo? Entonces reinicié la computadora y el problema desapareció.

También me encontré con este 9009problema al enfrentar una situación de sobrescritura.

Básicamente, si el archivo ya existe y no ha especificado el /ymodificador (que se sobrescribe automáticamente), este error puede ocurrir cuando se ejecuta desde una compilación.

De hecho, noté que por alguna razón la variable de entorno% windir% a veces se borra. Lo que funcionó para mí fue restablecer la variable de entorno windir a c: \ windows, reiniciar VS, y eso es todo. De esta forma, evita tener que modificar los archivos de la solución.

Al menos en Visual Studio Ultimate 2013, Versión 12.0.30723.00 Actualización 3, no es posible separar una instrucción if / else con un salto de línea:

trabajos:

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

no funciona

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

Otra razón más: si su evento previo a la compilación hace referencia a otra ruta de bin de proyectos y ve este error al ejecutar msbuild, pero no Visual Studio, entonces debe organizar manualmente los proyectos en el archivo * .sln (con un editor de texto) para que el proyecto al que se dirige en el evento se crea antes del proyecto del evento. En otras palabras, msbuild usa el orden en que los proyectos se enumeran en el archivo * .sln, mientras que VS usa el conocimiento de las dependencias del proyecto. Esto sucedió cuando una herramienta que crea una base de datos para ser incluida en un wixproj fue listada después del wixproj.

Creo que en mi caso había símbolos rusos en la ruta (todos los proyectos estaban en la carpeta del usuario). Cuando puse la solución en otra carpeta (directamente en el disco), todo se volvió correcto.

Mi solución fue crear una copia del archivo y agregar un paso a la tarea de compilación para copiar mi archivo sobre el original.

Debes asegurarte de haber instalado Grunt a nivel mundial