Pourquoi MSBuild recherche-t-il dans C: \ Microsoft.Cpp.Default.props au lieu de c: \ Program Files (x86) \ MSBuild? (erreur MSB4019)

124

Lorsque j'exécute msbuild pour créer un projet vc2010, j'obtiens l'erreur suivante:

error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. 
Confirm that the path in the <Import> declaration is correct, and that the file exists 
on disk.
  • msbuild situé c: \ Program File (x86) \ MSBuild
  • HKLM \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild \ ToolVersions \ V4.0 VCTargetsPath défini sur $ (MSBuildExtensionsPath32) \ Microsoft.Cpp \ v4.0 \
  • lors de l'exécution de msbuild / verbosity: diag as good system montre MSBuildExtensionsPath32, MSBuildExtensionsPath64, MSBuildExtensionsPath défini comme environnement au début de la construction
  • définir MSBuildExtensionsPath32, MSBuildExtensionsPath64, MSBuildExtensionsPath défini comme variables d'environnement dans le shell ne les fait pas apparaître comme environnement au début de la construction

Corrections tentées

  • .Net 4.5 désinstallé, réparé .net 4.0
  • Définissez MSBuildExtensionsPath32, MSBuildExtensionsPath64, MSBuildExtensionsPath dans les variables système.

Il semble que MSBuildExtensionsPath32 n'est pas défini correctement et la configuration de MSBuildExtensionsPath n'aide pas

SET MSBuildExtensionsPath="C:\Program Files\MSBuild"

S'il vous plaît laissez-moi savoir si vous avez des idées sur ce qui bloque le réglage approprié de cette variable.

msbuild Peter Kahn
la source
6
Génial! Une autre question sur une erreur résultant d'une installation corrompue de Visual Studio avec des centaines de solutions de contournement qui ne fonctionnent chacune que dans quelques scénarios sélectionnés ...
Florian Winter

Réponses:

75

J'ai eu ce problème lors de la publication d'une application cocos2d-x à l'aide de leur outil de ligne de commande, qui appelle MSBuild. J'utilise Win 7 64 bits, VS2013 express, cocos2d-x version 3.3, .NET Framework 4.5 installé.

J'ai résolu le problème en définissant ce qui suit avant d'exécuter la commande de publication cocos.py:

SET VCTargetsPath=C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120
Jeff
la source
Cela m'a aidé à installer le package de nœuds oracledb. J'ai suivi les instructions sur community.oracle.com/docs/DOC-931127 et même si j'ai eu l'erreur MSB4019, que j'ai corrigée avec cette réponse.
Pedro Otero le
1
Version PowerShell:[Environment]::SetEnvironmentVariable("VCTargetsPath", "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140", "Machine")
fiat
Aidé avec le chemin terminé avec 'v4.0'
Alexander
50

Pour ceux qui n'ont pas suivi l'ordre proscrit MS (voir la réponse de Xv ), vous pouvez toujours résoudre le problème.

MSBuild utilise VCTargetsPathpour localiser les propriétés cpp par défaut, mais ne le peut pas car le Registre ne dispose pas de cette valeur de chaîne.

Vérifiez la valeur de chaîne

  • Lancer regedit
  • Navigateur vers HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0
  • Inspectez la VCTargetsPathclé. La valeur devrait = " $(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\"

Réparer

  • Lancez regedit Navigator pour HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0
  • Ajouter une valeur de chaîne VCTargetsPath
  • Définir la valeur sur " $(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\"

Remarque: HKLMsignifie HKEY_LOCAL_MACHINE.

Peter Kahn
la source
12
L'entrée de registre était déjà là pour moi. J'ai dû définir une variable d'environnement avec ce nom défini sur la valeur dans le registre pour dépasser celle-là:set VCTargetsPath=c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0
elmotec
12
pour moi, cela n'a fonctionné qu'avec cet ensembleVCTargetsPath=c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v120
ygaradon
1
@ cmm-user HKLM signifie que HKEY_LOCAL_MACHINEvous devriez certainement l'avoir dans regedit
Michael Johnston
4
VCTargetsPath n'est pas une clé, mais une valeur de chaîne!
John Smith
5
Pour moi, c'était maintenantset VCTargetsPath=c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v140
Daniel Gray
26

J'ai eu le même problème récemment et après avoir installé différents packages dans un ordre différent, cela devenait très compliqué. Ensuite, j'ai trouvé ce repo - https://github.com/felixrieseberg/windows-build-tools

npm install --global windows-build-tools

Il installe les outils Python et VS Build nécessaires pour compiler la plupart des modules de nœuds. Cela a fonctionné un régal!

Luke
la source
1
Bonne chose mais ne fonctionne pas pour Azure malheureusement.
Aleksey Kontsevich
6
Pour ceux qui pourraient avoir un problème comme moi. J'avais besoin de l' --productionoption. npm install --global --production windows-build-tools Selon les instructions d'installation de node-gyp: github.com/nodejs/node-gyp
eliotRosewater
15

Pour Visual Studio 2017 et 2019 sur Windows 10

Un grand nombre des réponses ici s'appliquent aux anciennes versions de Visual Studio. Ce qui a fonctionné pour moi, si j'utilisais la version communautaire de Visual Studio 2017, était de définir une variable d'environnement appelée VCTargetsPathet de lui donner la valeur

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets

Si vous utilisez la version communautaire de Visual Studio 2019,

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160

D'autres réponses ici définissent cette variable sur c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v140mais j'ai remarqué que dans mon installation de Visual Studio, il n'y avait pas de dossier appelé Microsoft.Cpp dans mon dossier MSBuild. Gardez donc cela à l'esprit ainsi que le fait que le chemin ci-dessus concerne la version communautaire de Visual Studio 2017.

Assurez-vous également que votre chemin MSBuild dans vos variables d'environnement pointe vers la version correcte de MSBuild si vous utilisez la version communautaire de Visual Studio 2017,

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin

Si vous utilisez la version communautaire de Visual Studio 2019,

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin
Chris Gong
la source
1
Dans le mien, VCTargetPath était C: \ Program Files (x86) \ Microsoft Visual Studio \ 2017 \ BuildTools \ Common7 \ IDE \ VC \ VCTargets
Madura Pradeep
1
Il pourrait également s'agir de Microsoft Visual Studio\2019\BuildToolsvariantes similaires - et je suppose qu'au lieu de BuildTools et Community, vous pouvez également avoir Professional et Enterprise. vswhere.exe -products * -property installationPathrecherche toutes les combinaisons et renvoie les emplacements de tous les produits installés.
MSalters
1
'vswhere.exe' is not recognized as an internal or external command, operable program or batch file.
Andrew Koster
13

L'installation de la mise à jour du compilateur Microsoft Visual C ++ 2010 Service Pack 1 pour le SDK Windows 7.1 a corrigé les MSB4019erreurs que j'obtenais en construisant sur Windows7 x64.

Le readme de cette mise à jour indique que l'ordre recommandé est

  1. Visual Studio 2010
  2. SDK Windows 7.1
  3. Visual Studio 2010 SP1
  4. Mise à jour du compilateur Visual C ++ 2010 SP1 pour le SDK Windows 7.1
xverges
la source
Ah d'accord. J'ai trouvé le correctif pour cela. Ajoutez la clé de registre manquante. Je vais le publier et mettre à jour mes documents d'installation pour suivre cet ordre
Peter Kahn
6

Sur les systèmes 64 bits, MSBuild utilise par défaut les propriétés suivantes (où C: est SystemDrive):

MSBuildExtensionsPath = C:\Program Files (x86)\MSBuild
MSBuildExtensionsPath32 = C:\Program Files (x86)\MSBuild
MSBuildExtensionsPath64 = C:\Program Files\MSBuild

Si ce n'est pas le cas, cela signifie que vous avez installé des cibles de remplacement tierces personnalisées ou que votre installation MSBuild est corrompue.

Choses à essayer:

  • Réparer l'installation de .NET
  • Appliquer le dernier Service Pack Visual Studio
  • Définir MSBuildExtensionsPathmanuellement comme ci-dessus (notez la x86partie sur les machines 64 bits)
KMoraz
la source
2
Merci, mais ceux-ci ne sont toujours pas définis après: 1) repaire .net 4.5, 2) désinstaller .net 4.5 et réparer 4.0. Si je les définis manuellement dans l'environnement, cela ne fonctionne pas non plus
Peter Kahn
5

J'ai eu ce problème sur l'édition 2015 de Visual Studio. Lorsque j'ai utilisé cmake pour générer un projet, cette erreur est apparue.

erreur MSB4019: le projet importé "D: \ Microsoft.Cpp.Default.props" est introuvable

Je l'ai corrigé en ajoutant une chaîne

VCTargetsPath

avec valeur

$ (MSBuildExtensionsPath32) \ Microsoft.Cpp \ v4.0 \ V140

dans le chemin du registre

HKLM \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 14.0

Sjs
la source
C'est fait. Redémarré la cmd après, mais ne résout pas le problème.
Dan
4

MSBuild dans un outil de construction indépendant qui est souvent fourni avec d'autres outils. Il peut avoir été installé sur votre ordinateur avec .NET (anciennes versions), Visual Studio (versions plus récentes) ou même Team Foundation Build.

MSBuild a besoin de fichiers de configuration, de compilateurs, etc. (un ToolSet) qui correspond à la version de Visual Studio ou TFS qui l'utilisera, ainsi que de la version de .NET par rapport à laquelle le code source sera compilé.

Selon la façon dont MSBuild a été installé, les fichiers de configuration peuvent se trouver dans un ou plusieurs de ces chemins.

  • C: \ Program Files (x86) \ MSBuild \ Microsoft.Cpp \ v4.0 \
  • C: \ Program Files (x86) \ MSBuild \ Microsoft.Cpp \ v4.0 \ V120 \
  • C: \ Program Files (x86) \ MSBuild \ Microsoft.Cpp \ v4.0 \ V140 \

Comme décrit dans d'autres réponses, un élément de registre et / ou une variable d'environnement doit pointer vers le chemin ToolSet.

  • La clé VCTargetsPath sous HKLM \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0
  • La variable d'environnement VCTargetsPath.

Parfois, une opération telle que l'installation d'un outil laisse le registre et / ou la variable d'environnement mal définis. Les autres réponses sont toutes des variantes de leur résolution.

La seule chose que je dois ajouter est que la variable d'environnement n'a pas fonctionné pour moi lorsque j'ai laissé la fin \

mmesser314
la source
Ce! Nous avons eu des problèmes avec notre agent de build sans installation complète de VS2017. Nous avons réinstallé le "Workload" avec un ensemble d'outils VC donné - pas le composant individuel, et il a fait une installation correcte. Nous pensons que le programme d'installation de Visual Studio n'a pas placé le bon ensemble d'outils v141 sous VS2017 lors de notre installation de sélection de composants personnalisés.
Lars Pellarin
Pour moi, cela a aidé à résoudre le problème - un script que j'utilisais était de trouver «utilement» le mauvais msbuild.exe et de l'appeler explicitement.
Scovetta
4

Les entrées de registre pour la clé MSBuild ont bien fonctionné pour moi. Il est important de se rappeler que cela doit être fait pour les branches 64 bits ou 32 bits selon la version de MSBuild que vous exécutez. Je ne recommanderais pas d'utiliser des variables d'environnement car cela peut causer des problèmes dans différentes versions de MSBuild.

Ce fichier de registre corrige cela dans les deux cas:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild\ToolsVersions\14.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V140\\'))"
"VCTargetsPath10"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath10)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V110\\'))"
"VCTargetsPath12"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath12)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V120\\'))"
"VCTargetsPath14"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath14)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V140\\'))"

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild\ToolsVersions\14.0\10.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\'))"

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild\ToolsVersions\14.0\11.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V110\\'))"
"VCTargetsPath10"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath10)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V110\\'))"

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild\ToolsVersions\14.0\12.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V120\\'))"
"VCTargetsPath10"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath10)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V110\\'))"
"VCTargetsPath12"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath12)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V120\\'))"

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild\ToolsVersions\14.0\14.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V140\\'))"
"VCTargetsPath10"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath10)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V110\\'))"
"VCTargetsPath12"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath12)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V120\\'))"
"VCTargetsPath14"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath14)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V140\\'))"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V140\\'))"
"VCTargetsPath10"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath10)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V110\\'))"
"VCTargetsPath12"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath12)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V120\\'))"
"VCTargetsPath14"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath14)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V140\\'))"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0\10.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\'))"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0\11.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V110\\'))"
"VCTargetsPath10"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath10)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V110\\'))"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0\12.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V120\\'))"
"VCTargetsPath10"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath10)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V110\\'))"
"VCTargetsPath12"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath12)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V120\\'))"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0\14.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V140\\'))"
"VCTargetsPath10"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath10)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V110\\'))"
"VCTargetsPath12"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath12)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V120\\'))"
"VCTargetsPath14"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath14)','$(MSBuildExtensionsPath32)\\Microsoft.Cpp\\v4.0\\V140\\'))"
Konstantin Ineshin
la source
3

Rien d'autre n'a fonctionné pour moi sauf, en définissant le chemin comme:

C:\Program Files\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0
sowmiya lakshmi
la source
quel chemin dois-je définir?
Nageshwar Reddy Pandem
3

EDIT: Cela s'applique aux anciennes versions de Visual Studio / MSBuild (en particulier MSVC2015?). Avec des versions plus modernes, MSBuild est inclus dans Visual Studio Build Tools 2019, et les compilateurs sont situés à différents endroits et détectés de différentes manières.

Cela est dû à une incompatibilité des ensembles d'outils MSBuild installés et des paramètres de registre. Cela peut arriver si vous avez effectué une ou plusieurs des actions suivantes:

  • Installez plusieurs versions de Visual Studio dans le mauvais ordre
  • Désinstaller une ou plusieurs versions de Visual Studio
  • Apportez manuellement des modifications ou des modifications au Registre à l'installation de Visual Studio

La seule solution sûre et fiable consiste à réinstaller votre système d'exploitation. Si votre projet a besoin de plusieurs versions de Visual Studio pour générer, installez d'abord la version la plus ancienne . Ensuite, corrigez votre code afin de pouvoir utiliser un seul outil pour le créer, ou vous ou vos collègues serez à nouveau dans le même désordre bientôt.

Si ce n'est pas une option pour vous, lisez d'abord https://stackoverflow.com/a/41786593/2279059 pour une meilleure compréhension du problème et de ce que font réellement les différentes «solutions». Ensuite, en fonction de votre version et de votre configuration de Visual Studio, l'une des autres réponses ou variantes de celles-ci peut éventuellement vous aider.

Quelques autres indices:

Florian hiver
la source
2

L'installation de la mise à jour du compilateur Microsoft Visual C ++ 2010 Service Pack 1 pour le SDK Windows 7.1 a fonctionné pour moi. Cependant, j'ai rencontré des problèmes avec la mise à jour car j'avais déjà installé VS 2010 et VS 2010 SP1. Comme mentionné par Xv ci-dessus, le fichier readme.htm contient des solutions pour les problèmes d'installation les plus courants dans la section «Problèmes connus». Je suivrais les instructions du readme.htm et redémarrerais votre machine après chaque tentative de dépannage car certaines installations écrivent dans votre registre.

ventilateur
la source
2

Dans mon cas, j'ai ajouté une variable d'environnement VCTargetPathavec chemin

"C: \ Program Files (x86) \ Microsoft Visual Studio \ 2017 \ Professional \ Common7 \ IDE \ VC \ VCTargets \"

('\' à la fin est crucial, car les fichiers de solution du projet ont une référence au fichier "Microsoft cpp target".

De plus, à partir de Visual Studio 2017, MSBUILD vient avec Visual Studio - donc, les PATH variablebesoins doivent être mis à jour avec

C: \ Program Files (x86) \ Microsoft Visual Studio \ 2017 \ Professional \ MSBuild \ 15.0 \ Bin

La mise à jour VCTargetPathet les PATHvariables de MSBUILD et la construction ont corrigé l'erreur.

Arjun Krishna
la source
0

Je suis tombé sur cette erreur en écrivant un script de construction qui mettrait MSBuild sur le% PATH% après avoir fouillé de manière récursive dans le dossier C: \ Windows \ Microsoft.NET pour tous les fichiers MSBuild.exe trouvés. Le dernier hit trouvé était le répertoire placé sur le chemin. Étant donné que la dircommande atteindrait le Framework64dossier après Frameworkavoir obtenu l'un des MSBuild 64 bits mis sur mon chemin. J'essayais de créer une solution Visual Studio 2010 et j'ai fini par modifier ma chaîne de recherche de C:\Windows\Microsoft.NETà C:\Windows\Microsoft.NET\Frameworkafin que je me retrouve avec un MSBuild.exe 32 bits. Maintenant, mon fichier de solution se construit.

jxramos
la source
0

Je viens d'ajouter en VCTargetsPath={c:\...}tant que variable d'environnement à mon travail Hudson.

user2818782
la source
0

Pour mémoire, le fichier Microsoft.Cpp.Default.propspeut modifier la variable d'environnement VCTargetsPathet rendre les utilisations ultérieures de cette variable incorrectes. J'ai eu ce problème et je l'ai résolu en définissant VCTargetsPath10et VCTargetsPath11à la même valeur que VCTargetsPath.

Cela doit être adapté en fonction de la version VS que vous utilisez.

STM
la source
0

Je vois cela dans un environnement VS2017. Mon script de construction appelle d' VsDevCmd.batabord, et pour résoudre ce problème, j'ai défini la VCTargetsPathvariable d'environnement après VsDevCmdet avant d'appeler MSBuild:

set VCTargetsPath=%VCIDEInstallDir%VCTargets
Hugh
la source
0

Ajout de la réponse de Chris Gong sur VS2017 / 2019 ci-dessus (je n'ai pas encore l'autorisation de commentaires).

Si VS 2019 Build Tools est installé plutôt que le Visual Studio complet, les chemins d'accès aux fichiers sont légèrement différents. VCTargetsPath doit alors être

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\

Notez également la barre oblique inverse de fin - requise au moins dans mon cas (outils de construction TFS2017, VS2019). Modification correspondante de l'entrée PATH également.

Lars V
la source
0

J'étais confronté au même problème avec MSBuild pour VS 17

J'ai résolu ce problème en appliquant les étapes suivantes:

  • Dans mon cas, le Microsoft.Cpp.Default.propsfichier était situé à C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\VC\VCTargets , j'ai donc créé une VCTragetsPathchaîne dans le registre sous HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0avec valeur C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\VC\VCTargets

  • J'ai également fait fonctionner mon Jenkins en tant qu'utilisateur administrateur

Cela a résolu mon problème.

Hemant
la source
0

Au lieu de définir un chemin fixe, essayez d'abord ceci dans votre ligne de commande post-build:

SET VCTargetsPath=$(VCTargetsPath)

La variable '$ (VCTargetsPath)' semble être une macro visual-studio-macro liée à C ++ qui n'est pas affichée dans c # -sdk-projects comme une macro mais qui y est toujours disponible.

Sam
la source