Que signifie «sortie avec le code 9009» pendant cette construction?

Que veux dire ce message d'erreur? Que puis-je faire pour corriger ce problème?

AssemblyInfo.cs est sorti avec le code 9009

Le problème se produit probablement dans le cadre d'une étape de post-génération dans une solution .NET dans Visual Studio.

Avez-vous essayé de donner le chemin complet de la commande qui s'exécute dans la commande d'événement pré ou post-génération?

J'obtenais l'erreur 9009 en raison d'une xcopycommande d'événement post-génération dans Visual Studio 2008.

La commande s'est "xcopy.exe /Y C:\projectpath\project.config C:\compilepath\"terminée avec le code 9009.

Mais dans mon cas, c'était également intermittent. Autrement dit, le message d'erreur persiste jusqu'à un redémarrage de l'ordinateur et disparaît après un redémarrage de l'ordinateur. Il est de retour après un problème lié à distance que je n'ai pas encore découvert.

Cependant, dans mon cas, fournir la commande avec son chemin complet a résolu le problème:

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

Au lieu de simplement:

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

Si je n'ai pas le chemin complet, il s'exécute pendant un certain temps après un redémarrage, puis s'arrête.

Aussi, comme mentionné dans les commentaires de ce post, s'il y a des espaces dans le chemin complet, alors il faut des guillemets autour de la commande . Par exemple

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

Notez que cet exemple concernant les espaces n'est pas testé.

Le code d'erreur 9009 signifie que le fichier d'erreur est introuvable. Toutes les raisons sous-jacentes affichées dans les réponses ici sont une bonne inspiration pour comprendre pourquoi, mais l'erreur elle-même signifie simplement un mauvais chemin.

Cela se produit lorsque certains paramètres d'environnement manquent pour utiliser les outils Microsoft Visual Studio x86.
Par conséquent, essayez d'ajouter en tant que première commande dans vos étapes de post-génération:

Pour l'utilisation de Visual Studio 2010:

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

Comme @FlorianKoch l'a mentionné dans les commentaires, pour VS 2017, utilisez:

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

Il doit être placé avant toute autre commande.
Il définira l'environnement d'utilisation des outils Microsoft Visual Studio x86.

Très probablement, vous avez de l'espace dans votre chemin résultant.

Vous pouvez contourner cela en citant les chemins, permettant ainsi des espaces. Par exemple:

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

Avait la même variable après avoir changé la variable PATH à partir des variables environnementales dans Win 7. Le retour à la valeur par défaut a aidé.

J'ai rencontré l'erreur 9009 lorsque mon script d'événement post-génération a tenté d'exécuter un fichier de commandes qui n'existait pas dans le chemin spécifié.

J'ai provoqué cette erreur lorsque j'ai expurgé ma variable d'environnement Path. Après l'édition, j'ai accidentellement ajoutéPath= au début de la chaîne de chemin. Avec une telle variable de chemin mal formée, je n'ai pas pu exécuter XCopy sur la ligne de commande (aucune commande ou fichier introuvable) et Visual Studio a refusé d'exécuter l'étape post-génération, citant une erreur avec le code 9009.

XCopy réside généralement dans C: \ Windows \ System32. Une fois que la variable d'environnement Path a permis à XCopy d'être résolu à l'invite DOS, Visual Studio a bien construit ma solution.

Mon erreur exacte était

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

9009 signifie fichier introuvable, mais il n'a pas pu trouver la partie "iscc" de la commande.

Je l'ai corrigé en ajoutant ";C:\Program Files\Inno Setup 5 (x86)\"à la variable d'environnement système"path"

Si le script fait ce qu'il doit faire et que c'est juste Visual Studio qui vous dérange sur l'erreur que vous pouvez simplement ajouter:

exit 0

à la fin de votre script.

Vérifier l'orthographe. J'essayais d'appeler un exécutable mais le nom était mal orthographié et cela m'a donné le exited with code 9009message.

Dans mon cas, j'ai dû "CD" (Changer de répertoire) dans le répertoire approprié avant d'appeler la commande, car l'exécutable que j'appelais était dans mon répertoire de projet.

Exemple:

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

Une autre variante:

aujourd'hui j'appelle l'interpréteur python de cron dans win32 et je prends ExitCode (% ERRORLEVEL%) 9009, car le compte système utilisé par cron n'a pas de chemin vers le répertoire Python.

Le problème dans mon cas s'est produit lorsque j'ai essayé d'utiliser une commande sur la ligne de commande pour l'événement Post-build dans ma bibliothèque de classes de test. Lorsque vous utilisez des guillemets comme ceci:

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

ou si vous utilisez la console:

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

Cela a résolu le problème pour moi.

La réponse de tfa a été déclassée, mais peut en fait provoquer ce problème. Grâce à hanzolo, j'ai regardé dans la fenêtre de sortie et j'ai trouvé ce qui suit:

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.

Après avoir exécuté npm install -g gulp, j'ai cessé de recevoir cette erreur. Si vous obtenez cette erreur dans Visual Studio, vérifiez la fenêtre de sortie et voyez si le problème est une variable d'environnement non définie.

Assurez-vous également qu'il n'y a pas de sauts de ligne dans la fenêtre d'édition d'événement post-génération de votre projet. Parfois, la copie de la commande xcopy à partir du Web lorsqu'elle est multiligne et la collant dans VS provoquera un problème.

J'ai ajouté "> monFichier.txt" à la fin de la ligne dans l'étape de pré-génération, puis j'ai inspecté le fichier pour rechercher l'erreur réelle.

Pour moi, l'espace disque était faible et les fichiers qui ne pouvaient pas être écrits devaient être présents plus tard. D'autres réponses mentionnaient des fichiers manquants (ou des fichiers mal nommés / mal référencés par leur nom) - mais la cause principale était le manque d'espace disque.

Pour moi, cela s'est produit après la mise à niveau des packages de pépites d'une version PostSharp à la suivante dans une grande solution (~ 80 projets). J'ai des erreurs de compilation pour les projets qui ont des commandes dans les événements PreBuild.

'cmd' n'est pas reconnu comme une commande interne ou externe, un programme exploitable ou un fichier de commandes. C: \ Program Files (x86) \ MSBuild \ 14.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1249,5): erreur MSB3073: La commande "cmd / c C: \ GitRepos \ main \ ServiceInterfaces \ DEV.Config \ PreBuild.cmd ServiceInterfaces "est sorti avec le code 9009.

La variable PATH était corrompue et devenait trop longue avec plusieurs chemins répétés liés à PostSharp.Patterns.Diagnostics. Lorsque j'ai fermé Visual Studio et l'ai rouvert, le problème a été résolu.

Encore une autre variante de fichier introuvable, à cause des espaces dans le chemin. Dans mon cas, dans le script msbuild. J'avais besoin d'utiliser le style HTML & quot; chaînes dans la commande 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" />

Identique aux autres réponses, dans mon cas, c'était à cause du fichier manquant. Pour savoir quel est le fichier manquant, vous pouvez aller dans la fenêtre de sortie et il vous montrera immédiatement ce qui a disparu.

Pour ouvrir la fenêtre de sortie dans Visual Studio:

1. Ctrl + Alt + O
2. Affichage> Sortie

J'ai corrigé cela en redémarrant simplement Visual Studio - je venais de lancer dotnet tool install xxxdans une fenêtre de console et VS n'avait pas encore récupéré les nouvelles variables d'environnement et / ou les paramètres de chemin qui ont été modifiés, donc un redémarrage rapide a résolu le problème.

C'est assez basique, j'ai eu ce problème et un simple échec embarrassant.

L'application utilise des arguments de ligne de commande, je les ai supprimés puis ajoutés à nouveau. Soudain, le projet n'a pas pu être construit.

Visual Studio -> Propriétés du projet -> vérifiez que vous utilisez l'onglet 'Debug' (pas l'onglet 'Build Events') -> Arguments de ligne de commande

J'ai utilisé la zone de texte et Post / Pre-build, ce qui était faux dans ce cas.

Ma solution était simple: avez-vous essayé de l'éteindre et de la rallumer? J'ai donc redémarré l'ordinateur et le problème avait disparu.

J'ai également rencontré ce 9009problème face à une situation d'écrasement.

Fondamentalement, si le fichier existe déjà et que vous n'avez pas spécifié le /ycommutateur (qui écrase automatiquement), cette erreur peut se produire lors de l'exécution à partir d'une génération.

En fait, j'ai remarqué que pour une raison quelconque, la variable d'environnement% windir% est parfois effacée. Ce qui a fonctionné pour moi a été de redéfinir la variable d'environnement windir sur c: \ windows, de redémarrer VS, et c'est tout. De cette façon, vous évitez d'avoir à modifier les fichiers de solution.

Au moins dans Visual Studio Ultimate 2013, version 12.0.30723.00 Update 3, il n'est pas possible de séparer une instruction if / else avec un saut de ligne:

travaux:

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

ne fonctionne pas:

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

Encore une autre raison: si votre événement de pré-génération fait référence à un autre chemin bin de projets et que vous voyez cette erreur lors de l'exécution de msbuild, mais pas de Visual Studio, vous devez alors organiser manuellement les projets dans le fichier * .sln (avec un éditeur de texte) afin que le projet que vous ciblez dans l'événement est créé avant le projet de l'événement. En d'autres termes, msbuild utilise l'ordre dans lequel les projets sont répertoriés dans le fichier * .sln tandis que VS utilise la connaissance des dépendances de projet. J'ai eu cela quand un outil qui crée une base de données à inclure dans un wixproj a été répertorié après le wixproj.

Je pense que dans mon cas, il y avait des symboles russes dans le chemin (tous les projets étaient dans le dossier utilisateur). Quand j'ai mis la solution dans un autre dossier (directement sur le disque), tout s'est bien passé.

Ma solution était de créer une copie du fichier et d'ajouter une étape à la tâche de génération pour copier mon fichier sur l'original.

Vous devez vous assurer que vous avez installé grunt à l'échelle mondiale