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

Avez-vous essayé d’indiquer le chemin complet de la commande en cours d’exécution dans la commande d’événement avant ou après la génération?

Je recevais l’erreur 9009 en raison d’une xcopy événement de post-génération xcopy dans Visual Studio 2008.

La commande "xcopy.exe /YC:\projectpath\project.config C:\comstackpath\" sortie avec le code 9009.

Mais dans mon cas, c’était aussi intermittent. En d’autres termes, le message d’erreur persiste jusqu’au 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 son chemin complet a résolu le problème:

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

Au lieu de juste:

 xcopy.exe /YC:\projectpath\project.config C:\comstackpath\ 

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.

Comme mentionné dans les commentaires de cet article, s’il y a des espaces dans le chemin complet, il faut alors utiliser des guillemets autour de la commande . Par exemple

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

Notez que cet exemple en ce qui concerne les espaces n’est pas testé.

Cela se produit lorsque vous manquez certains parameters d’environnement pour utiliser les outils Microsoft Visual Studio 2010 x86.
Par conséquent, essayez d’append une première commande dans vos étapes de post-construction:

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

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

Code d’erreur 9009 signifie fichier d’erreur introuvable. Toutes les raisons sous-jacentes affichées dans les réponses sont une bonne source d’inspiration pour comprendre pourquoi, mais l’erreur elle-même signifie simplement un mauvais chemin.

Vous avez probablement de la place dans votre chemin résultant.

Vous pouvez contourner ce problème 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 modifié la variable PATH à partir de variables environnementales dans Win 7. Le retour à la valeur par défaut a été utile.

J’ai eu l’erreur 9009 lorsque mon script d’événement post-build essayait d’exécuter un fichier de commandes qui n’existait pas dans le chemin spécifié.

Si le script fait réellement ce qu’il doit faire et que c’est juste Visual Studio qui vous envoie une erreur sur l’erreur, vous pouvez simplement append:

 exit 0 

à la fin de votre script.

J’ai causé cette erreur lorsque j’ai supprimé 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 (pas de commande ou de fichier introuvable) et Visual Studio a refusé de lancer l’étape de post-génération en 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 de se résoudre à l’invite DOS, Visual Studio a bien construit ma solution.

Vérifier l’orthographe. J’essayais d’appeler un exécutable mais j’avais mal orthographié le nom et cela m’a permis de exited with code 9009 message exited with code 9009 .

Mon erreur exacte était

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

9009 signifie fichier non trouvé, 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"

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.

Dans mon cas, je devais d’abord “CD” (Change Directory) dans le répertoire approprié, avant d’appeler la commande, puisque l’exécutable que j’appelais se trouvait dans mon répertoire de projet.

Exemple:

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

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.

Assurez-vous également qu’il n’y a pas de sauts de ligne dans la fenêtre d’édition des événements post-construction de votre projet. Parfois, copier la commande xcopy à partir du Web lorsque celui-ci est multi-ligne et le coller dans VS provoquera un problème.

J’ai ajouté “> myFile.txt” à la fin de la ligne dans l’étape de pré-construction, 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 / incorrectement référencés par nom) – mais la cause principale était le manque d’espace disque.

Encore une autre variante de fichier non trouvée, à cause des espaces dans le chemin. Dans mon cas, dans le script msbuild. Je devais utiliser le style HTML & quot; chaînes dans la commande exec.

C’est assez basique, j’ai eu ce problème, et simple gênant.

Application use Arguments de la ligne de commande, je les ai supprimés puis rajoutés. Soudain, le projet n’a pas réussi à se construire.

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

J’ai utilisé la zone de texte et de post-construction, ce qui était faux dans ce cas.

Pour moi, cela s’est produit après la mise à niveau des paquets nuget d’une version de 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 utilisable 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 que je l’ai rouvert, le problème a été résolu.

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

 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. 

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 vérifiez si le problème est une variable d’environnement non définie.

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, redémarrez VS, et c’est tout. De cette façon, vous évitez de 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 de projet bin et que vous voyez cette erreur lors de l’exécution de msbuild, mais pas de Visual Studio, vous devez organiser manuellement les projets dans le fichier * .sln que le projet que vous ciblez dans l’événement est construit 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, alors que VS utilise la connaissance des dépendances du projet. Cela s’est produit lorsqu’un outil qui crée une firebase database à 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). Lorsque je mets la solution dans un autre dossier (directement sur le disque), tout va bien.

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

Comme les autres réponses, dans mon cas, c’était à cause du fichier manquant. Pour savoir quel est le fichier manquant, vous pouvez aller à la fenêtre de sortie et cela vous montrera tout de suite ce qui a disparu.

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

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

Ma solution consistait à créer une copie du fichier et à append une étape à la tâche de génération pour copier mon fichier sur l’original.

J’ai également rencontré ce problème 9009 face à une situation de remplacement.

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

Vous devez vous assurer que vous avez installé grunt globalement