MSBuild en cours d’exécution ne parvient pas à lire SDKToolsPath

J’ai un problème avec un script NAnt qui construisait correctement mon site Web basé sur .Net 2.0, lors de la compilation avec VS2008 et ses outils associés. J’ai récemment mis à niveau tous les fichiers de projet / solution vers VS2010, et maintenant ma construction échoue avec l’erreur suivante:

[exec] C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Microsoft.Common.targets (2249,9): erreur MSB3086: la tâche n’a pas trouvé “sgen.exe” à l’aide de S dkToolsPath “” ou du registre clé “HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v7.0A”. Assurez-vous que SdkToolsPath est défini et que l’outil existe dans l’emplacement approprié du processeur sous SdkToolsPath et que le Kit de développement Microsoft Windows est installé

Maintenant, j’ai des versions antérieures (.Net 3.5) du kit de développement Windows installé sur le serveur de génération et la structure .Net 4.0 complète est installée, mais je n’ai pas exécuté sur une version spécifique du Kit de développement logiciel (SDK) Windows 4.0.

Après un peu d’expérimentation et de recherche, je viens de configurer une nouvelle variable d’environnement “SDKToolsPath” et de la diriger vers la copie de sgen.exe dans mon dossier Windows 6.0 sdk. Cela a généré la même erreur, mais cela m’a fait remarquer que même si la variable d’environnement SDKToolsPath est définie (ce qui confirme que je peux “faire écho” à la ligne de commande et qu’elle a la valeur attendue), le message d’erreur semble indiquer ne pas être lu (notez les guillemets vides).

La plupart des informations que j’ai trouvées sont spécifiques à .Net 3.5 (ou antérieures). Pas beaucoup 4.0 liés encore là-bas. La recherche du code d’erreur MSB3086 n’a généré rien non plus. Une idée de ce que cela pourrait être?

Scott

J’ai dû mordre la balle et installer VS 2010 sur notre serveur de compilation pour résoudre ce problème. Autant que je sache, il n’existe aucune version 7.0A du kit de développement Windows disponible sur MSDN. Toutefois, l’installation de VS 2010 semble l’installer, en créant une clé de licence 7.0A et un dossier 7.0A dans Program Files \ Microsoft SDKs \ Windows.

Je ne pouvais pas faire face à mettre Visual Studio sur le serveur de compilation.

Le SDK v7.0A est le SDK installé avec Visual Studio 2010 (le A indique qu’il s’agit d’une version VS). Depuis lors, une nouvelle version a été publiée. Microsoft Windows SDK pour Windows 7 et .NET Framework AKA v7.1 .

Je l’ai installé sur mon serveur de compilation. Et puis, via l’invite de commandes Windows SDK 7.1 (Démarrer => Tous les programmes => Microsoft Windows SDK 7.1), j’ai défini la version par défaut du SDK comme étant 7.1.

Pas:

cd Setup WindowsSdkVer.exe -version:v7.1 

Modifier pour inclure le commentaire de LordHits: il n’est pas nécessaire d’installer le SDK entier. L’installation des options “Développement .NET / Intellisense et de référence” et “.NET Développement / Outils” suffit.

Il suffit de transmettre le paramètre GenerateSerializationAssemblies avec la valeur Off à votre MsBuild.

 msbuild.exe /p:GenerateSerializationAssemblies=Off 

J’ai récemment rencontré un problème similaire sur notre serveur de compilation.

J’ai copié le dossier 7.0A (C: \ Program Files \ Microsoft SDKs \ Windows \ 7.0A) de mon ordinateur (sur lequel est installé VS2010) sur le serveur de génération situé au même emplacement.

Après avoir créé la clé de Registre suivante: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v7.0A. Définissez InstallationFolder sur C: \ Program Files \ Microsoft SDKs \ Windows \ 7.0A.

Vous pouvez également référencer le registre sur votre ordinateur avec VS2010 déjà installé si vous ne savez pas quoi faire avec le registre sur le serveur de génération.

J’ai rencontré la même erreur mais dans une autre situation: utiliser VS 2010 Express et essayer d’utiliser la réponse de Simmo pour définir explicitement la version du SDK. Cependant, WindowsSdkVer.exe (outil de définition de version) ne semble pas cibler Express (compréhensible car limité ).

J’utilise VS 2010 Express sur Win 7 Prof. et il veut toujours utiliser la version 7.0A de Win SDK (qui ne possède pas tous les exes nécessaires), et peu importe la version que j’utilise explicitement comme courant en utilisant WindowsSdkVer.exe (il continue à signaler qu’il a défini la version actuelle du SDK, mais pour VS 2008, même si 2010 Ex est installé uniquement).

Donc, ma solution de rechange bon marché consistait à installer la version 7.0 WIN SDK (ou une autre version comme la version 7.1), puis à renommer son dossier de système de fichiers en version 7.0A .

Je passe manuellement les variables à MSBuild sur le serveur de compilation.

msbuild.exe MyProject.csproj "/p:TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools" "/p:AspnetMergePath=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools"

Je soupçonne que le fichier cible remplace le chemin des outils, j’ai jeté un coup d’oeil rapide dans ce fichier et définit le SDKToolsPath sur $ TargetFrameworkSDKToolsDirectory sous certaines des cibles qu’il contient. Je ne pense pas que vous deviez de toute façon les définir dans l’environnement, mais ils pourraient avoir besoin d’être corrigés dans vos fichiers de projet.

Notez que selon cette page http://nant.sourceforge.net/ Nant ne supporte pas .Net 4.0, cela pourrait-il être le vrai problème?

Désolé, je sais que cela ne répond pas vraiment à votre question 🙁

Un de vos projets utilise sgen.exe (Server Generator) pour générer un service Web. Vous devez installer les kits de développement logiciel pour créer un serveur ou supprimer les références de service Web du projet.

Vous n’avez pas installé la version 7.0A de SDK? C’est un problème que vous devrez résoudre. Regardez dans les fichiers journaux d’installation du VS2010 pour voir ce qui s’est mal passé. Le SDK doit être présent dans c: \ program files \ microsoft sdks \ windows \ 7.0a et la clé de registre répertoriée doit également être présente. Exécuter avec la version 6.0a de sgen.exe n’est pas correct, il est lié à utiliser le mauvais compilateur.

Définissez Sdk40ToolsPath plutôt que SdkToolsPath pour spécifier un emplacement autre que le répertoire d’installation.

J’ai rencontré un problème similaire avec AL.exe car je venais de copier les outils sur la machine de génération plutôt que d’installer le SDK, de sorte que les clés de registre habituelles étaient manquantes. J’ai exécuté une version avec sortie de diagnostic (/ verbosity: diagnostic) et j’ai remarqué que plusieurs chemins d’outils du SDK étaient définis: Sdk40ToolsPath, Sdk35ToolsPath et SdkToolsPath. Définir Sdk40ToolsPath pour qu’il pointe vers le dossier bin de la version du SDK approprié a résolu le problème pour moi.

J’ai eu le même problème sur une nouvelle machine Windows 10. Ma configuration:

  • Windows 10
  • Visual Studio 2015 installé
  • SDK Windows 10

Mais je ne pouvais pas construire de projets .NET 4.0:

Die Aufgabe konnte “AL.exe” avec une démo SdkToolsPath-Wert “ou un fichier de registre” HKEY_LOCAL_MACHINE \ LOGICIELS \ Microsoft \ Microsoft SDKs \ Windows \ v8.0A \ WinSDK-NetFx40Tools-x86

Solution: Après avoir essayé (et échoué) d’installer le SDK Windows 7 (car il comprend également le SDK 4.0 .NET), je devais installer le SDK Windows 8 et m’assurer que le «SDK .NET Framework 4.5» était installé.

C’est fou … mais a travaillé.

Je suis d’accord avec la réponse de IanS. Pas besoin d’installer un nouveau SDK. Assurez-vous simplement que les valeurs de clé de registre SDK35ToolsPath et SDK40ToolPath pour MSBuild pointent vers les valeurs de clé de registre correctes.

Dans mon cas, mon projet était ciblé sur .NET 3.5 et je devais définir SDK35ToolsPath pour la clé HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 sur $ (Registre: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v6.0A \ WinSDKNetFxTools @ InstallationFolder). Et tout a fonctionné.

Nous avons un pc de compilation WinXP et utilisons Visual Build Pro 6 pour construire notre logiciel. Comme certains de nos développeurs utilisent VS 2010, les fichiers de projet contiennent désormais une référence à la “version 4.0 de l’outil” et d’après ce que je peux dire, cela indique à Visual Build qu’il doit trouver quelque part sdk7.x, même si . Cela l’a empêché de trouver lc.exe. J’ai essayé de le tromper en pointant toutes les macros vers le sdk 6.0A fourni avec VS2008 qui est installé sur le PC, mais cela ne fonctionnait pas.

J’ai fini par le faire fonctionner en téléchargeant et en installant sdk 7.1. J’ai ensuite créé une clé de registre pour 7.0A et orienté le chemin d’installation vers le chemin d’installation du sdk 7.1. maintenant il trouve heureusement un “lc.exe” compatible et tout le code comstack bien. J’ai l’impression que je pourrai maintenant comstackr le code .NET 4.0 même si VS2010 n’est pas installé, mais je n’ai pas encore essayé.

ToolsVersion = “4.0” le fait pour moi dans mon projet MSBuild:

  

J’ai eu ce même problème et avait installé Windows SDK 7.0 et Windows SDK 7.1 qui n’a pas résolu le problème. La cause du problème était que la bibliothèque de classes incriminée était construite avec Target Framework de .NET Framework 2.0.

Je l’ai changé pour .NET Framework 4.0 et travaillé localement et, une fois coché dans le serveur de compilation, il l’a construit avec succès.

J’ai eu un problème similaire, notamment msbuild échoue: MSB3086, MSB3091: “AL.exe”, “resgen.exe” introuvable

Sur une machine Windows 7 64 bits, j’ai installé .Net Framework 4.5.1 et Windows SDK for Windows 8.1.

Bien que les configurations pour le SDK indiquent qu’il était à jour, ce n’était probablement pas le cas. J’ai résolu le problème en supprimant toutes les versions installées du SDK, puis en installant les éléments suivants dans cet ordre:

http://www.microsoft.com/en-us/download/details.aspx?id=3138

http://www.microsoft.com/en-us/download/details.aspx?id=8279

http://msdn.microsoft.com/en-us/windows/desktop/hh852363.aspx

http://msdn.microsoft.com/en-us/windows/desktop/aa904949.aspx

Réponse courte: Dans le fichier .csproj, il existe un moyen de spécifier le chemin d’access à sgen.exe, à l’aide de SGenToolPath:

   C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools  

Votre chemin peut être différent, mais SGenToolPath est ce que vous voulez.

Pour obtenir une liste des autres propriétés courantes du projet MSBuild, voir: https://msdn.microsoft.com/en-us/library/bb629394.aspx

Nous avons fini par utiliser ce paramètre SGenToolPath dans le fichier .csproj, au lieu de modifier les valeurs du registre sur le serveur de génération. L’édition des valeurs de registre sur ma machine locale avait également bien fonctionné, mais c’était un peu plus compliqué et nous ne voulions pas gâcher le registre sur le serveur de compilation.

Pour le Registre: Dans ce cas, le problème était que les SDK40ToolsPath sous HKLM \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild pointaient vers une valeur de Registre $ (Registre: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v8.0A \ WinSDK-NetFx40Tools-x86 @ InstallationFolder) qui n’existait pas. Je viens de remplacer cela directement par le chemin réel.

Assurez-vous d’abord que vous avez déjà téléchargé le fichier dotNetFx40_Full_x86_x64.exe et installé (il est généralement associé à Visual Stdio).

Ensuite, définissez rapidement une nouvelle variable d’environnement sur les variables système. comme ci-dessous: "TargetFrameworkSDKToolsDirectory":"C:\Program Files (x86)\Microsoft SDKs\Windows\vxx.0A\bin\NETFX 4.6.1 Tools" //note:the path:'\vxx.0A\' is a variable indicating your version. it's '\v10.0A\' for me. : "TargetFrameworkSDKToolsDirectory":"C:\Program Files (x86)\Microsoft SDKs\Windows\vxx.0A\bin\NETFX 4.6.1 Tools" //note:the path:'\vxx.0A\' is a variable indicating your version. it's '\v10.0A\' for me. "TargetFrameworkSDKToolsDirectory":"C:\Program Files (x86)\Microsoft SDKs\Windows\vxx.0A\bin\NETFX 4.6.1 Tools" //note:the path:'\vxx.0A\' is a variable indicating your version. it's '\v10.0A\' for me.

Outre les mods de registre, vous devrez peut-être modifier la version du fichier .net de vos parameters définis dans Visual Studio.

J’avais ce problème et j’ai décidé de vérifier les parameters de débogage du projet.

Project => Propriétés de la barre d’outils => Bouton Options de compilation Advance Debug

Le framework cible (toutes les configurations) a été défini sur 3.0, ce qui n’est pas le cas sur mon système.

J’ai changé cela en 4.0, puis j’ai dû redémarrer le projet et Visual Studio 2010.

Le projet a ensuite été construit sans erreurs et a été exécuté.

J’avais un problème similaire. J’avais fait un projet en utilisant Visual Studio 2010 et puis j’ai eu l’erreur ci-dessus lorsque je l’ai compilé à l’aide de Visual Studio 2012 . J’ai simplement copié tout le contenu de C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A dans C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A et cela a résolu mon problème.

Je viens d’avoir cette erreur avec un fichier .sln qui a été créé à l’origine dans Visual Studio 2010 (et en cours de construction par Visual Studio 2010 et TFS 2010). J’avais modifié le fichier de solution pour ne PAS construire un projet qui n’était pas censé être construit dans une configuration particulière et Visual Studio a modifié l’en-tête du fichier de solution à partir de:

 Microsoft Visual Studio Solution File, Format Version 11.00 # Visual Studio 2010 

À:

 Microsoft Visual Studio Solution File, Format Version 12.00 # Visual Studio 14 VisualStudioVersion = 14.0.24720.0 MinimumVisualStudioVersion = 10.0.40219.1 

Le remettre à la version originale de 2010 a résolu mon problème. Je suppose que la compatibilité avec Visual Studio n’a toujours pas été améliorée.

essayez d’utiliser la “réparation” du studio visuel. Cela a fonctionné pour moi.

Emballage CMD
J’ai essayé toutes les choses d’ici et même plus. Rien ne m’a aidé.

J’ai appliqué un wrapper CMD pour MSBuild et DevEnv.com.
L’idée principale d’un tel wrapper est de créer un environnement préparé en appelant des invites de commande à partir de Visual Studio supply. Ensuite, transmettez les parameters d’entrée standard à un appel de MSBuild ou de DevEnv.com.

Quoi qu’il en soit, sur mon serveur de compilation, je peux maintenant créer des projets à partir de différentes versions de Visual Studio.

Comment utiliser
J’ai dû remplacer les appels à MSBuild et DevEnv par un appel à mes wrappers de fichiers de commandes.
Et je n’ai modifié aucun paramètre d’entrée. Comme exemple pour mon appel de wrapper MSBuild:

MsBuild_Wrapper.bat MySolution.sln /target Build /property:Configuration=Release

Solution prête
En fait, j’ai eu beaucoup plus de problèmes avec une migration de VS 2010 vers VS 2015. Mais celle-ci était la première et la plus difficile.
Donc, ma modeste recette de sauvetage pour Build Server est ici. Il est peut-être difficile de comprendre tout ce style CMD dès le premier moment, mais toute logique est évidente, je l’espère.

Astuces
Il y a
MSBuild Command Prompt for Visual Studio et Developer Command Prompt for Visual Studio
Je les utilise correctement pour MSBuild et DevEnv.com. Mais l’invite de commande MSBuild sera probablement suffisante.

Pour VS 2015, ces invites de commande sont ici C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\ . Ou consultez le menu des programmes Windows.

Pour transmettre tous les parameters d’entrée à MSBuild ou DevEnv dans un fichier de commandes, j’ai utilisé CALL MSBuild %*