¿Qué significa “salido con el código 9009” durante esta comstackció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 comstackció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 construcción?

xcopy el error 9009 debido a un comando de evento xcopy post-build en Visual Studio 2008.

El comando "xcopy.exe /YC:\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 reiniciar la computadora. Está de vuelta después de algún problema remotamente relacionado que todavía no he descubierto.

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

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

En lugar de simplemente

 xcopy.exe /YC:\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.

También como se menciona en los comentarios a esta publicación, si hay espacios en el camino completo, entonces se necesitan comillas alrededor del comando . P.ej

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

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

Sucede cuando falta la configuración de entorno para usar las herramientas de Microsoft Visual Studio 2010 x86.
Por lo tanto, intente agregar como primer comando en sus pasos posteriores a la comstackción:

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

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

El código de error 9009 significa que no se encuentra 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.

Lo más probable es que tengas espacio en tu camino resultante.

Puede solucionar esto citando las rutas, permitiendo 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 al valor predeterminado ayudó.

Tuve el error 9009 cuando mi secuencia de comandos post evento de comstackción estaba tratando de ejecutar un archivo por lotes que no existía en la ruta especificada.

Si el script realmente hace lo que necesita hacer y es solo Visual Studio que te está molestando sobre el error que podrías agregar:

 exit 0 

al final de tu guión.

Hice que ocurriera este error cuando redacté mi variable de entorno Path. Después de la edición, accidentalmente agregué Path= al comienzo de la cadena de ruta. Con una variable de ruta de acceso tan mal formada, no pude ejecutar XCopy en la línea de comandos (no se encontró ningún comando o archivo), y Visual Studio se negó a ejecutar el paso posterior a la construcción, citando un error con el código 9009.

XCopy generalmente reside en C: \ Windows \ System32. Una vez que la variable de entorno Path permitió a XCopy resolverse en el prompt de DOS, Visual Studio construyó bien mi solución.

Revisar la ortografía. Intenté llamar a un ejecutable pero el nombre estaba mal escrito y me dio el mensaje exited with code 9009 .

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"

Otra variante:

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

En mi caso, tuve que “CD” (Cambiar directorio) primero en el directorio correcto, antes de llamar al comando, ya que el ejecutable al que estaba llamando estaba en mi directorio de proyecto.

Ejemplo:

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

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

 "$(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í.

Además, asegúrese de que no haya saltos de línea en la ventana de edición de eventos posteriores a la comstackción en su proyecto. A veces copiar el comando xcopy desde la web cuando es multi-línea y pegarlo en VS causará un problema.

Agregué “> myFile.txt” al final de la línea en el paso previo a la comstackción y luego inspeccioné el archivo para ver el error real.

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

Sin embargo, otra variante de archivo no se encuentra, debido a espacios en la ruta. En mi caso en el script msbuild. Necesitaba usar el estilo HTML & quot; cadenas dentro del comando exec.

   

Esto es bastante básico, tuve este problema, y ​​el simple error embarazoso.

Uso de la aplicación Argumentos de línea de comandos, los eliminé y luego los agregué de nuevo. De repente, el proyecto no pudo construir.

Visual Studio -> Propiedades del proyecto -> verifica que usas la pestaña ‘Depurar’ (no la pestaña ‘Crear eventos’) -> Argumentos de la línea de comando

Utilicé el área de texto de Publicar / Preconstruir, que fue incorrecto en este caso.

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

‘cmd’ no se reconoce como un comando interno o externo, progtwig operable o archivo por lotes. C: \ Archivos de progtwig (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 volvió demasiado larga con varias rutas repetidas relacionadas con PostSharp.Patterns.Diagnostics. Cuando cerré Visual Studio y lo abrí de nuevo, el problema se solucionó.

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

 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. 

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

De hecho, noté que por alguna razón la variable de entorno% windir% a veces se borraba. Lo que funcionó para mí fue volver a establecer la variable de entorno windir en c: \ windows, reiniciar VS, y eso es todo. De esta forma evitará 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 de precomstackción hace referencia a otra ruta bin de proyectos y ve este error cuando ejecuta msbuild, pero no Visual Studio, entonces tiene que organizar manualmente los proyectos en el archivo * .sln (con un editor de texto) para que el proyecto al que se dirige en el evento está construido 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 utiliza 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 incluida después de la 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 quedó bien.

Mi solución fue simple: ¿has intentado apagar y encender nuevamente? Así que reinicié la computadora y el problema desapareció.

Al igual que las otras respuestas, en mi caso fue por falta de archivo. 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

enter image description here

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

También encontré este problema 9009 cuando enfrentaba una situación de sobrescritura.

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

Debes asegurarte de haber instalado el ronco globalmente