L'exécution de MSBuild ne parvient pas à lire SDKToolsPath

Howdy, j'ai un peu de problème à exécuter un script NAnt qui a utilisé pour construire 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 pu trouver "sgen.exe" à l'aide du 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 le bon emplacement spécifique du processeur sous SdkToolsPath et que le SDK Microsoft Windows est installé

Maintenant, j'ai des versions antérieures (.Net 3.5) du SDK Windows installées sur le serveur de build, et le framework .Net 4.0 complet est installé, mais je n'ai pas exécuté sur une version spécifique .Net 4.0 du SDK Windows.

Après un peu d'expérimentation et de recherche, j'ai finalement juste configuré une nouvelle variable d'environnement "SDKToolsPath" et l'ai pointée vers la copie de sgen.exe dans mon dossier sdk de Windows 6.0. 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 (j'ai confirmé que je peux la "faire écho" sur la ligne de commande et qu'elle a la valeur attendue), le message d'erreur semble indiquer qu'elle est non lu (notez les guillemets vides).

La plupart des informations que j'ai trouvées sont spécifiques à .Net 3.5 (ou version antérieure). Pas encore beaucoup de 4.0 lié là-bas. La recherche du code d'erreur MSB3086 n'a généré rien d'utile 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 construction pour résoudre ce problème. Pour autant que je sache, il n'y a pas de version 7.0A du SDK Windows disponible n'importe où sur MSDN. Cependant, l'installation de VS 2010 semble l'installer, créant une clé de registre 7.0A et un dossier 7.0A dans Program Files \ Microsoft SDKs \ Windows.

Je ne pouvais pas faire face à l'installation de Visual Studio sur le serveur de build.

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

J'ai installé ceci sur mon serveur de build. Et puis via l'invite de commande du SDK Windows 7.1 (Démarrer => Tous les programmes => Microsoft Windows SDK 7.1), j'ai défini la version par défaut du SDK sur 7.1.

Pas:

cd Setup

WindowsSdkVer.exe -version:v7.1

Modifiez pour inclure le commentaire de LordHits: il n'est pas nécessaire d'installer tout le SDK. L'installation des options "Développement .NET / Intellisense et Assemblys de référence" et "Développement .NET / Outils" suffit.

Passez simplement le paramètre GenerateSerializationAssemblies avec la valeur Off à votre MsBuild.

msbuild.exe /p:GenerateSerializationAssemblies=Off

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

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"

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

J'ai copié le dossier 7.0A (C: \ Program Files \ Microsoft SDKs \ Windows \ 7.0A) de mon ordinateur (sur lequel VS2010 est installé) sur le serveur de construction 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 sur lequel VS2010 est déjà installé si vous ne savez pas quoi faire avec le registre sur le serveur de build.

J'ai rencontré la même erreur mais dans une situation différente: 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 il est limité ).

J'utilise VS 2010 Express sur Win 7 Prof.et il veut toujours utiliser la v7.0A du SDK Win (qui n'a pas tous les exes nécessaires), et peu importe la version que j'ai explicitement définie comme utilisation actuelle WindowsSdkVer.exe (il continue de signaler qu'il a défini la version actuelle du SDK mais pour VS 2008 bien que je n'ai installé que 2010 Ex.)

Donc, ma solution de contournement bon marché était d'installer v7.0 WIN SDK (ou une autre version comme la v7.1), puis de renommer son dossier de système de fichiers en v7.0A - en gros, je viens de mentir à VS 2010 Express mais cela fonctionne maintenant!

L'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 (SDK) pour créer le serveur ou supprimer les références de service Web du projet.

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

Notez que d'après cette page http://nant.sourceforge.net/ Nant ne prend pas en charge .Net 4.0, est-ce que cela pourrait être le vrai problème?

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

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

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

Mais je ne pouvais pas créer de projets .NET 4.0:

Die Aufgabe konnte "AL.exe" mit dem SdkToolsPath-Wert "" ou dem Registrierungsschlüssel "HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v8.0A \ WinSDK-NetFx40Tools-x86

Solution: après avoir essayé (et échoué) d'installer le SDK Windows 7 (car il inclut également le SDK .NET 4.0), je devais installer le SDK Windows 8 et m'assurer que le "SDK .NET Framework 4.5" est installé.

C'est fou ... mais ça marche.

Vous n'avez pas installé la version 7.0A du SDK? C'est un problème que vous devrez résoudre. Regardez dans les fichiers journaux d'installation de VS2010 pour voir ce qui ne va pas. 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. L'exécution avec la version 6.0a de sgen.exe n'est pas acceptable, il est lié à l'utilisation du mauvais compilateur.

Définissez Sdk40ToolsPathplutôt que SdkToolsPathde spécifier un emplacement autre que le répertoire d'installation.

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

Je suis d'accord avec la réponse d'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é pour .NET 3.5 et j'ai dû 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 construction winXP et utilisons Visual Build Pro 6 pour créer notre logiciel. comme certains de nos développeurs utilisent VS 2010, les fichiers de projet contiennent désormais une référence à la «version de l'outil 4.0» et d'après ce que je peux dire, cela indique à Visual Build qu'il doit trouver un sdk7.x quelque part, même si nous ne construisons que pour .NET 3.5 . 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 n'a pas fonctionné.

J'ai finalement réussi à 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 indiqué 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 se compile correctement. J'ai le sentiment que je serai désormais capable de compiler du code .NET 4.0 même si VS2010 n'est pas installé, mais je ne l'ai pas encore essayé.

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

<Project DefaultTargets="Do" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

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

Ensuite, définissez rapidement de nouvelles variables d'environnement dans 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.

J'ai eu ce même problème et j'avais installé Windows SDK 7.0 et Windows SDK 7.1 qui n'ont pas résolu le problème. La cause du problème pour moi était que la bibliothèque de classes incriminée a été créée avec Target Framework de .NET Framework 2.0.

Je l'ai changé en .NET Framework 4.0 et ai travaillé localement et une fois vérifié dans le serveur de construction, il l'a construit avec succès.

J'ai eu un problème similaire, notamment msbuild échoue: MSB3086, MSB3091: "AL.exe", "resgen.exe" non trouvé

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

Bien que les configurations du SDK disaient 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 ce qui suit, 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 vers sgen.exe, à l'aide de SGenToolPath:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="14.0">
  <PropertyGroup>
    <SGenToolPath>C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools</SGenToolPath>
  </PropertyGroup>

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

Pour obtenir la 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 de registre sur le serveur de génération. La modification des valeurs de registre sur ma machine locale avait également fonctionné, mais était un peu plus compliquée et nous ne voulions pas gâcher le registre sur le serveur de construction.

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

J'ai aussi rencontré ce problème en essayant de créer un plugin à l'aide de Visual Studio 2017 sur mon ordinateur de travail horriblement en désordre. Si vous recherchez sur Internet "impossible de trouver resgen.exe", vous pouvez trouver tous ces conseils du type " utilisez simplement regedit pour modifier votre registre Windows et créez une nouvelle clé ici et copiez-collez le contenu de ce dossier dans cet autre dossier, bla bla bla. '

J'ai passé des semaines à gâcher mon registre Windows avec regedit, j'ai probablement ajouté une douzaine de sous-clés et copié-collé ResGen.exe dans de nombreux répertoires différents, en le mettant parfois dans un dossier `` bin '', parfois en le gardant simplement dans le dossier principal, etc.

En fin de compte, j'ai réalisé: "Hé, si Visual Studio donnait un message d'erreur plus détaillé, rien de tout cela ne poserait problème." Donc, afin d'obtenir plus de détails sur l'erreur, j'ai exécuté MSBuild.exe directement sur mon fichier * .csproj à partir de la ligne de commande:

 "C:/Windows/Microsoft.NET/Framework/v4.0.3.0319/MSBuild.exe C:/Users/Todd/Plugin.csproj -fl -flp:logfile="C:/Users/Todd/Desktop/error_log.log";verbosity=diagnostic"

Bien sûr, vous devrez modifier les détails du chemin en fonction de votre situation, mais assurez-vous de mettre 1) le chemin complet de MSBuild.exe 2) le chemin complet de votre fichier * .csproj 3) le -fl -flp: logfile = part, qui indiquera à MSBuild de créer un fichier journal de chaque étape du processus, 4) l'emplacement où vous souhaitez que le fichier * .log soit enregistré et 5); verbosity = diagnostic, qui indique simplement à MSBuild pour inclure des tonnes de détails dans le fichier * .log.

Après cela, la génération échouera comme toujours, mais il vous restera un fichier * .log indiquant exactement où MSBuild a recherché votre fichier ResGen.exe. Dans mon cas, près du bas du fichier * .log, j'ai trouvé:

Compiling plug-in resources (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6.2\WinSDK-NetFx40Tools-x86 (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6.1\WinSDK-NetFx40Tools-x86 (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6\WinSDK-NetFx40Tools-x86 (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\Windows\v8.1a\WinSDK-NetFx40Tools-x86 (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\Windows\v8.0a\WinSDK-NetFx40Tools-x86 (Task ID:41)
MSBUILD: error : Failed to locate ResGen.exe and unable to compile plug-in resource file "C:/Users/Todd/PluginResources.resx"

Donc, fondamentalement, MSBuild a cherché dans cinq répertoires distincts pour ResGen.exe, puis a abandonné. C'est le genre de détails que vous ne pouvez tout simplement pas obtenir du message d'erreur Visual Studio, et cela résout le problème: utilisez simplement regedit pour créer une clé pour l'un de ces cinq emplacements et mettez la valeur «InstallationFolder» dans la clé , qui doit pointer vers le dossier dans lequel réside votre ResGen.exe (dans mon cas, c'était "C: \ Program Files \ Microsoft SDKs \ Windows \ v10.0A \ bin \ NETFX 4.7.2 Tools").

Si vous êtes un spécialiste des sciences humaines comme moi sans expérience en informatique, vous serez peut-être tenté de simplement modifier votre registre Windows et de copier-coller ResGen.exe partout lorsque vous êtes confronté à une erreur comme celle-ci (qui est bien sûr, mauvaise pratique). Il est préférable de suivre la procédure décrite ci-dessus: 1) Exécutez MSBuild.exe directement sur votre fichier * .csproj pour trouver l'emplacement exact que MSBuild recherche pour ResGen.exe puis 2) modifiez votre registre Windows avec précision afin que MSBuild puisse trouver ResGen. EXE.

Je l'ai corrigé en passant ceci en tant que paramètre de ligne de commande à msbuild.exe:

Votre kilométrage variera en fonction de la version du SDK que vous avez sur votre système

/p:TargetFrameworkSDKToolsDirectory="C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools

Outre les mods de registre, vous devrez peut-être modifier la version du sdk .net définie par vos paramètres dans Visual Studio.

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

Projet => Propriétés de la barre d'outils => Bouton Options de compilation avancée de débogage

Le cadre cible (toutes les configurations) a été défini sur 3.0, ce qui n'est pas 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 s'est ensuite construit sans erreur et s'est exécuté.

J'avais un problème similaire. J'avais fait un projet en utilisant Visual Studio 2010et puis j'ai obtenu l'erreur ci-dessus lorsque je l'ai compilé en utilisant Visual Studio 2012. J'ai simplement copié tout le contenu de C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0Adedans C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0Aet 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 changé l'en-tête du fichier de solution 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 rétrocompatibilité dans Visual Studio n'a toujours pas été perfectionnée.

essayez d'utiliser la «réparation» de Visual Studio. 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é des wrappers CMD pour MSBuild et DevEnv.com.
L'idée principale à l'intérieur d'un tel wrapper est de créer un environnement préparé en appelant des invites de commande à partir de Visual Studio Supply. Et puis passez les paramètres d'entrée standard à un appel de MSBuild ou DevEnv.com.

Quoi qu'il en soit, sur mon serveur de génération, 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 changé aucun paramètre d'entrée. À titre d'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 à VS 2015. Mais celle-ci était la première et la plus difficile.
Donc, ma modeste recette de sauvetage pour un serveur de construction est ici. Il est peut-être difficile de comprendre tout ce style CMD dès le premier instant mais toute logique est évidente, j'espère.

Astuces
Il existe
MSBuild Command Prompt for Visual Studioet Developer Command Prompt for Visual Studio
je les utilise de manière appropriée 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 regardez dans le menu des programmes Windows.

Pour passer tous les paramètres d'entrée à MSBuild ou DevEnv dans un fichier batch que j'ai utilisé CALL MSBuild %*