.net - ventajas - visual studio code
¿Qué significa "salido con el código 9009" durante esta compilación? (29)
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é ocurriendo 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 anterior o posterior a la compilación?
Recibí el error 9009 debido a un comando de evento post-build xcopy 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 el reinicio de la computadora y desaparece después de reiniciar la computadora. Vuelvo después de algún problema remotamente relacionado que todavía tengo que descubrir.
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 sólo
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.
También como se menciona en los comentarios a esta publicación, si hay espacios en la ruta completa, entonces uno necesita 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 está probado.
Además, asegúrese de que no haya saltos de línea en la ventana de edición de eventos de compilación posterior en su proyecto. A veces, copiar el comando xcopy desde la web cuando es multilínea 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 en busca del error real.
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)
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í simplemente significa un mal camino.
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 puso bien.
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 de Windir a c: / windows, reiniciar VS, y eso es todo. De esa forma evitas tener que modificar los archivos de la solución.
El problema en mi caso ocurrió cuando intenté usar un comando en la línea de comandos para el evento posterior a la compilación en mi biblioteca de clases de prueba. Cuando usas 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í.
En mi caso, primero tenía que "CD" (Cambiar directorio) al directorio adecuado, 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"
Esto es bastante básico, tuve este problema, y avergonzante simple falla.
La aplicación usa argumentos de la línea de comandos, los quité 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 ''Eventos de compilación'') -> Argumentos de línea de comando
Utilicé el área de texto y Publicar / Pre-compilación, lo cual estaba mal en este caso.
He tenido el error 9009 cuando mi secuencia de comandos de sucesos de compilación posterior intentaba ejecutar un archivo por lotes que no existía en la ruta especificada.
Hice que ocurriera este error cuando redaccioné la variable de entorno de mi ruta. Después de editar, accidentalmente agregué Path= al principio de la cadena de ruta. Con tal variable de ruta con formato incorrecto, 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 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 construyó bien mi solución.
La respuesta de tfa ha sido reducida, pero en realidad puede causar este problema. Gracias a hanzolo, miré 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 está obteniendo este error en Visual Studio, verifique la ventana de salida y vea si el problema es una variable de entorno no configurada.
Lo más probable es que tengas espacio en tu camino resultante.
Puede solucionar este problema citando las rutas, permitiendo así espacios. Por ejemplo:
xcopy "$(SolutionDir)/Folder Name/File To Copy.ext" "$(TargetDir)" /R /Y /I
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"
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.
Mi solución fue simple: ¿has intentado apagarla y volver a encenderla? Así que reinicié la computadora y el problema desapareció.
Necesitas asegurarte de haber instalado grunt globalmente
Ocurre cuando le faltan algunas configuraciones 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 compilación:
call "$(DevEnvDir)../Tools/vsvars32.bat"
Debe colocarse antes de cualquier otro comando.
Configurará el entorno para usar las herramientas Microsoft Visual Studio 2010 x86.
Otra razón más: si su evento de precompilación hace referencia a otra ruta de la bandeja de proyectos y ve este error al ejecutar msbuild, pero no a Visual Studio, entonces debe organizar los proyectos manualmente en el archivo * .sln (con un editor de texto) para que que el proyecto al que se dirige en el evento se construya antes del proyecto del evento. En otras palabras, msbuild usa el orden en que se enumeran los proyectos en el archivo * .sln, mientras que VS usa el conocimiento de las dependencias del proyecto. Ocurrió esto cuando una herramienta que crea una base de datos para ser incluida en un wixproj fue listada después del wixproj.
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=""$(MSBuildThisFileDirectory)/wix/wixscript.bat" $(VersionNumber) $(VersionNumberShort)"
ContinueOnError="false"
IgnoreExitCode="false"
WorkingDirectory="$(MSBuildProjectDirectory)/wix" />
Otra variante:
hoy llamo a python interpreter desde cron en win32 y tomo ExitCode (% ERRORLEVEL%) 9009, porque la cuenta del sistema utilizada por cron no tiene ruta al directorio de Python.
Para mí, el espacio en disco era bajo y se esperaba que los archivos que no se podían escribir estuvieran presentes más tarde. Otras respuestas mencionaron archivos faltantes (o archivos mal nombrados / incorrectamente referenciados por nombre), pero la causa raíz fue la falta de espacio en el 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 (~ 80 proyecto). Tengo errores de compilación para proyectos que tienen comandos en eventos de PreBuild.
''cmd'' no se reconoce como un comando interno o externo, un programa operable o un 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 varias rutas repetidas relacionadas con PostSharp.Patterns.Diagnostics. Cuando cerré Visual Studio y lo abrí de nuevo, el problema se solucionó.
Revisar la ortografía. Estaba intentando llamar a un ejecutable, pero escribí mal el nombre y me dio el mensaje de exited with code 9009 .
Si la secuencia de comandos realmente hace lo que debe hacer y es solo Visual Studio le está molestando sobre el error que podría agregar:
exit 0
hasta el final de su guión.
También me encontré con este problema 9009 al enfrentar una situación de sobrescritura.
Básicamente, si el archivo ya existe y no ha especificado el modificador /y (que se sobrescribe automáticamente), este error puede ocurrir cuando se ejecuta desde una compilación.
Tuvo la misma variable después de cambiar la variable PATH de Variables ambientales en Win 7. Cambiar de nuevo a predeterminado ayudó.