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


130

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


Problème lié dans ce post. J'y ai aussi posté une réponse. stackoverflow.com/questions/1109955/…
Diego C.

Réponses:


15

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.


9
Je préfère ne pas installer Visual Studio 2010 sur un serveur. Je préfère la suggestion de Simmo ci-dessous de définir le SDK Windows actuel sur la version 7.1. WindowsSdkVer.exe se trouve dans C: \ Program Files \ Microsoft SDKs \ Windows \ v7.1 \ Setup (en supposant qu'il a été installé dans C: \ Program Files).
Philippe

55
J'ai constaté que si vous installez uniquement Windows SDK 7.1 et .NET 4.0. MSBuild ne définit pas les chemins d'accès appropriés vers SDK40ToolsPath et SDK35ToolsPath. Pour y remédier, j'ai dû modifier quelques entrées dans HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0: "SDK40ToolsPath" = "$ (Registre: HKEY_LOCAL_MACHINE \\ SOFTWARE \\ Microsoft \\ Microsoft SDKs \\ Windows \\ v7 .1 \\ WinSDK-NetFx40Tools-x86 @ InstallationFolder) "De même, remplacez" v7.0A "par" v7.1 "dans SDK35ToolsPath et FrameworkSDKRoot.
BlueMonkMN

7
Sheesh - J'ai à nouveau rencontré le même problème moi-même, je l'ai cherché sur Google et j'ai trouvé ma propre réponse! :) Quelque chose semble avoir réinitialisé ma modification et je suppose que je dois l'appliquer à nouveau manuellement.
BlueMonkMN le

3
ARRRGH! Les derniers correctifs .NET 4.0 (2011-08-11) ont remplacé ces paramètres de registre!
si618

8
Mise à jour sur ma réponse précédente. Il semble que sur les systèmes d'exploitation 64 bits, il peut également être nécessaire de mettre à jour des valeurs similaires dans HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild \ ToolsVersions \ 4.0, et il peut être nécessaire d'installer le SDK 8.0 ou de mettre à jour les valeurs dans HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 \ 11.0 et HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 \ 11.0 J'ai fait tout ce qui précède, sauf l'installation du SDK 8.0, et je n'ai pas pu compiler jusqu'à ce que je (en un seul lot step) inclus mes mises à jour de tous les nœuds 4.0 \ 11.0.
BlueMonkMN

227

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.


4
Cela a parfaitement fonctionné pour moi, combiné à la copie des fichiers dans C: \ Program Files \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications à partir de ma machine VS.
dnolan

1
J'étais confronté au même problème que l'auteur original et cette réponse l'a résolu! Je n'avais pas besoin d'installer Visual Studio 2010 sur ma machine de génération.
SolutionYogi

37
Aussi, juste pour clarifier, 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. Ceci et copie des fichiers du commentaire de dnolan.
LordHits

Merci pour cette solution, cela a parfaitement fonctionné pour moi sur notre serveur de build! Pour info, pour quiconque pose des questions, le serveur de build est Windows Server 2008 x64.
Adam Weber

Merci beaucoup pour cette réponse; a également rencontré le même problème au travail.
Abe

20

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

msbuild.exe /p:GenerateSerializationAssemblies=Off

7
msbuild.exe / p: GenerateSerializationAssemblies = Off
Daniel

2
Ou définissez "Générer l'assemblage de sérialisation: Désactivé" dans l'onglet Générer des propriétés du projet du service Web.
samneric

6
Qu'est-ce que cela fait exactement?
écraser le

1
GOTCHA: Si vous le désactivez dans l'onglet de construction, assurez-vous de le faire pour la configuration de construction qui est pertinente, (DropDown en haut de l'onglet Build) dans mon cas, c'était juste le serveur de construction avec le problème, donc je devais modifiez-le dans la configuration «Release».
Myster

14
J'adore changer de façon aléatoire les drapeaux de construction sans aucune idée de ce qu'ils font réellement.
AaronLS

14

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"

1
C'est ce que j'ai fini par faire pour un SDK Windows 10 sur un serveur sans Visual Studio et Build Tools 2019. Aucune des autres solutions ne semblait aider et celle-ci a fait l'affaire de manière propre.
Nicolás Fantone

8

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.


Pour moi, la réponse de Simmo n'a pas fonctionné - ce hack de registre a bien fonctionné (Win 2K3 SP2).
FinnNk du

7

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!


5

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.


1
Ou définissez "Générer l'assemblage de sérialisation: Désactivé" dans l'onglet Générer des propriétés du projet du service Web.
samneric

1
GOTCHA: Si vous le désactivez dans l'onglet de construction, assurez-vous de le faire pour la configuration de construction qui est pertinente, (DropDown en haut de l'onglet Build) dans mon cas, c'était juste le serveur de construction avec le problème, donc je devais modifiez-le dans la configuration «Release».
Myster

4

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 :(


Correct, NAnt ne prend pas encore en charge les formats de fichier projet / solution pour VS2010, c'est pourquoi j'appelle MSBuild pour l'étape de compilation proprement dite. Va extraire le fichier des cibles.
Scott Mayfield

4

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.


Cela m'a également aidé sur Windows 10.
bourbert

3

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.


1
N'oubliez pas qu'il s'agit d'un serveur de build, donc l'installation de l'environnement VS2010 complet n'était pas mon premier choix. Je n'ai pas pu trouver de téléchargement disponible du SDK Windows 7.0a
Scott Mayfield

3
Je ne vois pas le problème. Exécuter une compilation sur une machine dont la configuration ne correspond pas aux machines de développement, c'est un problème qui vous épuisera rapidement.
Hans Passant

3

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.


Où avez-vous défini Sdk40ToolsPath?
Michael Freidgeim

Je suppose qu'il doit être ajouté au chemin de l'environnement. Cependant, cela n'a pas fonctionné pour moi.
Timothy Lee Russell

Désolé, c'était il y a si longtemps que j'ai oublié les détails, mais je pense que c'était soit une variable d'environnement soit définie dans le fichier de projet MSBuild. Notez également que la question d'origine concerne .NET Framework 4.0 / VS2010, mais différentes variables peuvent être nécessaires pour les versions ultérieures du framework.
IanS

2

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é.


2

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é.


2

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">

Eh bien, dans mon cas, j'ai utilisé ToolsVersion = "14.0" pour VS 2015 et cela a résolu le problème
AndrewSilver

2

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.


Cela résout le problème. Juste un indice si quelqu'un a le même problème que moi. La variable Env doit être appelée TargetFrameworkSDKToolsDirectory et non SdkToolsPath !!!
Markus

1

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.


1

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


1

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.


1

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.


J'ai essayé cela mais pour une raison quelconque, je n'obtiens pas la liste des chemins que vous affichez. J'ai trouvé un article similaire au vôtre sur ce site: community.sdl.com/developers-more/developers/ ... donc je sais que cela devrait fonctionner, mais en vain. Quelle version de MSBuild utilisez-vous?
user11809641

On dirait que j'utilise MSBuild version 4.0.30319. J'ai également la version 3.5, 3.0 et 2.0.50727 installée sur cet ordinateur. J'ai essayé d'exécuter ces versions de MSBuild sur mon fichier * .csproj (de la même manière que celle décrite ci-dessus), mais cela n'a pas fonctionné ... je n'ai même pas créé de fichier * .log. /// Lorsque vous exécutez MSBuild sur votre fichier * .csproj, l'ordinateur produit-il au moins un fichier * journal? Je crois comprendre qu'il existe un fichier journal, mais aucune information spécifique concernant les chemins qui ont été recherchés lors de la recherche de ResGen.exe - est-ce correct?
todbott

On dirait que j'ai la même version de MSBuild (4.0.30319). Et oui, vous avez raison. Je reçois un fichier journal, mais il ne donne aucune information sur les chemins du registre. Lequel des cinq chemins que vous publiez ci-dessus avez-vous fini par utiliser?
user11809641

J'ai utilisé le 1er chemin de la liste - je viens d'ajouter un "InstallationFolder" dans la clé SOFTWARE \ WOW6432Node \ Microsoft \ Microsoft SDKs \ NETFXSDK \ 4.6.2 \ WinSDK-NetFx40Tools-x86. De plus, le fichier * .log est en fait extrêmement long - des milliers de lignes, dans mon cas. Je n'ai pas pu trouver les informations de chemin à l'œil nu. J'ai fini par ouvrir le fichier * .log dans le Bloc-notes et rechercher "ResGen.exe", ce qui a attiré mon attention sur la zone pertinente (informations sur les chemins).
todbott

1
Super - félicitations! Vous êtes devenu l'une des rares personnes (quelques centaines, je suppose) à avoir combattu les erreurs et le mystère et à avoir compilé avec succès un plugin pour Trados. Bonne chance pour la publication de votre plugin, rendez-vous sur l'Appstore SDL!
todbott

1

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

0

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'ai fait une erreur c'est localiser à ce qui suit. Projet => Propriétés de la barre d'outils => Bouton Compiler les options de compilation avancées J'ai également créé un nouveau projet et le nouveau projet .net a été défini sur 3.0. Il sera donc nécessaire de modifier également le paramètre par défaut. Scott A. Tovey
Scott Tovey

J'ai découvert que lorsque vous créez un projet, en haut de la fenêtre, il y a une liste déroulante de tous les frameworks. Tout est répertorié, qu'il soit installé ou non. Une fois que vous avez sélectionné un cadre et créé un projet à partir de cette liste, il reste la valeur par défaut jusqu'à ce que vous le changiez en un autre cadre pour un nouveau projet. C'est un peu imprudent, la liste ne doit contenir que les frameworks installés sur le système.
Scott Tovey

0

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.


3
J'aimerais qu'il y ait un vote pour la pire solution du monde. Ce serait ça.
jonypony3

0

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.


0

essayez d'utiliser la «réparation» de Visual Studio. Cela a fonctionné pour moi.


0

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 %*

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.