Question

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

Assemblyinfo.cs sorti avec le code 9009


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

Pas de solution correcte

Autres conseils

Avez-vous essayé de donner le chemin complet de la commande qui s'exécute dans la commande de l'événement avant ou post-construction?

J'obtenais l'erreur 9009 en raison d'un xcopy Commande d'événements post-construction dans Visual Studio 2008.

La commande "xcopy.exe /Y C:\projectpath\project.config C:\compilepath\" sorti avec le code 9009.

Mais dans mon cas, c'était aussi 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 à distance lié 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 /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 fonctionne pendant un certain temps après un redémarrage, puis s'arrête.

Également comme mentionné sur les commentaires de ce post, S'il y a des espaces En plein chemin, alors il faut 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 en ce qui concerne les espaces n'est pas testé.

Le code d'erreur 9009 signifie le fichier d'erreur introuvable. Toutes les raisons sous-jacentes publié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 vous manquez des paramètres d'environnement pour l'utilisation d'outils Microsoft Visual Studio X86.
Par conséquent, essayez d'ajouter en première commande dans vos étapes post-construction:

Pour Visual Studio 2010 Utilisation:

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

Comme @floriankoch l'a mentionné dans les commentaires, pour vs 2017 use:

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

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

Vous avez probablement de l'espace dans votre chemin qui en résulte.

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 modifié la variable de chemin à partir des variables environnementales dans Win 7. Changer de retour en défaut a aidé.

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

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

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

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

exit 0

à la fin de votre script.

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

Dans mon cas, j'ai dû d'abord "CD" (modifier le répertoire) au 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"

Mon erreur exacte était

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

9009 signifie le 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"

Une autre variante:

Aujourd'hui, j'appelle Python Interpreter de CRON dans Win32 et prends EXITCODE (% ErrorLevel%) 9009, car le compte système utilisé par Cron n'a pas de chemin d'accès à Python Directory.

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-construction dans ma bibliothèque de classe de test. Lorsque vous utilisez des guillemets comme tel:

"$(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 rupture de ligne dans la fenêtre d'édition d'événements de build de post sur votre projet. Parfois, la copie de la commande xcopy à partir du Web lorsqu'elle est multi-ligne et la collier en VS causera un problème.

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

La réponse de TFA a été votée en baisse, mais peut en fait causer 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 coulé npm install -g gulp, J'ai cessé d'obtenir 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.

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 ont mentionné les fichiers manquants (ou les fichiers mal nommés / mal référencés par nom) - mais la cause profonde était le manque d'espace disque.

Encore une autre variante du fichier introuvable, en raison des espaces dans le chemin. Dans mon cas dans le script MSBuild. J'avais besoin d'utiliser le style HTML " 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 accéder à la fenêtre de sortie et cela 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

enter image description here

J'ai corrigé cela en redémarrant simplement Visual Studio - je venais de courir dotnet tool install xxx Dans une fenêtre de console et VS n'avait pas encore ramassé les nouvelles variables d'environnement et / ou 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 échec simple embarrassant.

Application Utilisez des arguments de ligne de commande, je les ai supprimés, puis je les ai ajoutés. Soudain, le projet n'a pas réussi à construire.

Visual Studio -> Propriétés du projet -> Vérifiez que vous utilisez l'onglet «Debug» (non «Build Events» Tab) -> Arguments de ligne de commande

J'ai utilisé la zone de texte post / pré-construction, ce qui était faux dans cette affaire.

Pour moi, cela s'est produit après avoir mis à niveau les packages NuGet d'une version post-sharp à la suivante dans une grande solution (~ 80 projet). J'ai des erreurs de compilateur pour des projets qui ont des commandes dans les événements pré-construites.

«CMD» n'est pas reconnu comme une commande interne ou externe, un programme opérable ou un fichier batch. 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 "sorti avec le code 9009.

La variable de chemin a été corrompue devenant trop longue avec plusieurs chemins répétés liés à postsharp.patterns.diagnostics. Lorsque j'ai fermé Visual Studio et que j'ai ouvert à nouveau, le problème a été résolu.

Ma solution était juste simple comme: avez-vous essayé de le désactiver et de se rendre à nouveau? J'ai donc redémarré l'ordinateur et le problème avait disparu.

J'ai aussi rencontré ça 9009 Problème face à une situation d'écrasement.

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

En fait, j'ai remarqué que pour une raison quelconque, la variable de l'environnement%% Windir% est parfois effacée. Ce qui a fonctionné pour moi a été de réinitialiser la variable de l'environnement Windir à C: Windows, redémarrer vs, et c'est tout. De cette façon, vous empêchez d'avoir à modifier les fichiers de solution.

Au moins dans Visual Studio Ultimate 2013, version 12.0.30723.00 Mise à jour 3, il n'est pas possible de séparer une déclaration if / else avec une pause en ligne:

œuvres:

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 pré-construction fait référence à un autre chemin de bin projets et que vous voyez cette erreur lors de l'exécution de msbuild, mais pas de Visual Studio, vous devez arranger manuellement les projets dans le fichier * .sln (avec un éditeur de texte) donc Que le projet que vous visez dans l'événement soit construit avant le projet de l'événement. En d'autres termes, MSBuild utilise l'ordre selon lequel les projets sont répertoriés dans le fichier * .sln tandis que vs utilise des connaissances des dépendances du projet. Je me suis produit lorsqu'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 sur PATH (tous les projets étaient dans le dossier utilisateur). Lorsque je mets une solution dans un autre dossier (directement sur le disque), tout est devenu correct.

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

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

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top