Beim Ausführen von MSBuild kann SDKToolsPath nicht gelesen werden


130

Grüß dich, ich habe ein kleines Problem beim Ausführen eines NAnt-Skripts, mit dem meine .NET 2.0-basierte Website beim Kompilieren mit VS2008 und den zugehörigen Tools ordnungsgemäß erstellt wurde. Ich habe kürzlich alle Projekt- / Lösungsdateien auf VS2010 aktualisiert und jetzt schlägt mein Build mit dem folgenden Fehler fehl:

[exec] C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Microsoft.Common.targets (2249,9): Fehler MSB3086: Task konnte "sgen.exe" mit S dkToolsPath "" oder der Registrierung nicht finden Schlüssel "HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v7.0A". Stellen Sie sicher, dass SdkToolsPath festgelegt ist und das Tool am richtigen prozessorspezifischen Speicherort unter SdkToolsPath vorhanden ist und dass das Microsoft Windows SDK installiert ist

Jetzt habe ich frühere Versionen (.Net 3.5) des Windows SDK auf dem Build-Server installiert, und das vollständige .NET 4.0-Framework ist installiert, aber ich habe keine .NET 4.0-spezifische Version des Windows SDK ausgeführt.

Nach einigem Experimentieren und Nachforschen habe ich endlich eine neue Umgebungsvariable "SDKToolsPath" eingerichtet und auf die Kopie von sgen.exe in meinem Windows 6.0 SDK-Ordner verwiesen. Dies erzeugte den gleichen Fehler, aber ich bemerkte, dass die SDKToolsPath-Umgebungsvariable zwar gesetzt ist (bestätigt, dass ich sie in der Befehlszeile "echo" kann und sie den erwarteten Wert hat), die Fehlermeldung jedoch anzeigt, dass dies der Fall ist nicht gelesen werden (beachten Sie die leeren Anführungszeichen).

Die meisten Informationen, die ich gefunden habe, sind .NET 3.5 (oder früher) spezifisch. Es gibt noch nicht viel 4.0. Die Suche nach dem Fehlercode MSB3086 hat ebenfalls nichts Nützliches generiert. Irgendeine Idee, was das sein könnte?

Scott


Verwandte Ausgabe in diesem Beitrag. Ich habe dort auch eine Antwort gepostet. stackoverflow.com/questions/1109955/…
Diego C.

Antworten:


15

Ich musste in die Kugel beißen und VS 2010 auf unserem Build-Server installieren, um dieses Problem zu beheben. Soweit ich sehen kann, ist auf MSDN nirgendwo eine 7.0A-Version des Windows SDK verfügbar. Bei der Installation von VS 2010 wird es jedoch anscheinend installiert, indem ein 7.0A-Registrierungsschlüssel und ein 7.0A-Ordner unter Programme \ Microsoft SDKs \ Windows erstellt werden.


9
Ich bevorzuge es, Visual Studio 2010 nicht auf einem Server zu installieren. Ich bevorzuge Simmos folgenden Vorschlag, das aktuelle Windows SDK auf Version 7.1 einzustellen. WindowsSdkVer.exe befindet sich unter C: \ Programme \ Microsoft SDKs \ Windows \ v7.1 \ Setup (vorausgesetzt, es wurde unter C: \ Programme installiert).
Philippe

55
Ich habe festgestellt, dass, wenn Sie nur Windows SDK 7.1 und .NET 4.0 installieren. MSBuild legt keine richtigen Pfade zu SDK40ToolsPath und SDK35ToolsPath fest. Um dies zu beheben, musste ich einige Einträge in HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 ändern: "SDK40ToolsPath" = "$ (Registrierung: HKEY_LOCAL_MACHINE \\ SOFTWARE \\ Microsoft \\ Microsoft SDKs \\ Windows \\ v7 .1 \\ WinSDK-NetFx40Tools-x86 @ InstallationFolder) "Ändern Sie" v7.0A "in SDK35ToolsPath und FrameworkSDKRoot auf ähnliche Weise in" v7.1 ".
BlueMonkMN

7
Meine Güte - ich bin selbst wieder auf dasselbe Problem gestoßen, habe danach gegoogelt und meine eigene Antwort gefunden! :) Etwas scheint meine Änderung zurückgesetzt zu haben und ich denke, ich muss sie erneut manuell anwenden.
BlueMonkMN

3
ARRRGH! Die neuesten .NET 4.0-Patches (2011-08-11) haben diese Registrierungseinstellungen überschrieben!
Si618

8
Update zu meiner früheren Antwort. Unter 64-Bit-Betriebssystemen müssen möglicherweise auch ähnliche Werte in HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 aktualisiert werden. Möglicherweise muss das 8.0 SDK installiert oder die Werte in HKEY_LOCAL_MACHINE \ aktualisiert werden SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 \ 11.0 und HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 \ 11.0 Ich habe alle oben genannten Schritte ausgeführt, außer das 8.0 SDK zu installieren, und konnte erst als ich (als ein Stapel) kompilieren Schritt) enthielt meine Updates für alle 4.0 \ 11.0-Knoten.
BlueMonkMN

227

Ich konnte es nicht ertragen, Visual Studio auf den Build-Server zu stellen.

Das SDK v7.0A ist das mit Visual Studio 2010 installierte SDK (Das A gibt an, dass es sich um eine VS-Version handelt). Seitdem wurde eine neuere Version veröffentlicht. Microsoft Windows SDK für Windows 7 und .NET Framework AKA v7.1 .

Ich habe dies auf meinem Build-Server installiert. Und dann habe ich über die Windows SDK 7.1-Eingabeaufforderung (Start => Alle Programme => Microsoft Windows SDK 7.1) die Standardversion des SDK auf 7.1 festgelegt.

Schritte:

cd Setup

WindowsSdkVer.exe -version:v7.1

Bearbeiten, um den Kommentar von LordHits aufzunehmen: Es muss nicht das gesamte SDK installiert werden. Es reicht aus, nur die Optionen ".NET Development / Intellisense und Referenzassemblies" und ".NET Development / Tools" zu installieren.


4
Dies funktionierte perfekt für mich, kombiniert mit dem Kopieren der Dateien von meinem VS-Computer in C: \ Programme \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications.
Dnolan

1
Ich hatte das gleiche Problem wie der ursprüngliche Autor und diese Antwort löste es! Ich musste Visual Studio 2010 nicht auf meinem Build-Computer installieren.
SolutionYogi

37
Zur Verdeutlichung muss nicht das gesamte SDK installiert werden. Es reicht aus, nur die Optionen ".NET Development / Intellisense und Referenzassemblies" und ".NET Development / Tools" zu installieren. Dies und das Kopieren der Dateien aus dnolans Kommentar.
LordHits

Vielen Dank für diese Lösung, sie hat auf unserem Build-Server perfekt funktioniert! Zu Ihrer Information: Für alle, die Fragen haben, ist der Build-Server Windows Server 2008 x64.
Adam Weber

Vielen Dank für diese Antwort. stieß auch bei der Arbeit auf dasselbe Problem.
Abe

20

Übergeben Sie einfach den Parameter GenerateSerializationAssemblies mit dem Wert Off an Ihre MsBuild.

msbuild.exe /p:GenerateSerializationAssemblies=Off

7
msbuild.exe / p: GenerateSerializationAssemblies = Off
Daniel

2
Oder setzen Sie "Serialisierungsassembly generieren: Aus" auf der Registerkarte "Erstellen" der Projekteigenschaften des Webdienstes.
Samneric

6
Was macht das genau?
Crush

1
GOTCHA: Wenn Sie es auf der Registerkarte "Build" deaktivieren, stellen Sie sicher, dass Sie dies für die relevante Build-Konfiguration tun (DropDown oben auf der Registerkarte "Build"). In meinem Fall war es nur der Build-Server mit dem Problem, also musste ich Ändern Sie dies in der 'Release'-Konfiguration.
Myster

14
Ich liebe es, Build-Flags zufällig zu wechseln, ohne eine Ahnung zu haben, was sie tatsächlich tun.
AaronLS

14

Ich übergebe die Variablen manuell an MSBuild auf dem Build-Server.

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
Dies habe ich letztendlich für ein Windows 10 SDK auf einem Server ohne Visual Studio und Build Tools 2019 getan. Keine der anderen Lösungen schien zu helfen, und diese hat den Trick auf saubere Weise ausgeführt.
Nicolás Fantone

8

Ich habe kürzlich ein ähnliches Problem auf unserem Build-Server festgestellt.

Ich habe den Ordner 7.0A (C: \ Programme \ Microsoft SDKs \ Windows \ 7.0A) von meinem Computer (auf dem VS2010 installiert ist) auf den Build-Server am selben Speicherort kopiert.

Erstellen Sie nach dem Erstellen des folgenden Registrierungsschlüssels: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v7.0A. Setzen Sie InstallationFolder auf C: \ Programme \ Microsoft SDKs \ Windows \ 7.0A.

Sie können auch auf die Registrierung auf Ihrem Computer verweisen, auf der VS2010 bereits installiert ist, wenn Sie sich nicht sicher sind, was Sie mit der Registrierung auf dem Buildserver tun sollen.


Für mich hat Simmos Antwort nicht funktioniert - dieser Registrierungs-Hack hat jedoch funktioniert (Win 2K3 SP2).
FinnNk

7

Ich bin auf denselben Fehler gestoßen, aber in einer anderen Situation: Verwenden von VS 2010 Express und Versuch, Simmos Antwort zum expliziten Festlegen der SDK-Version zu verwenden - WindowsSdkVer.exe (Versionseinstellungstool) scheint jedoch nicht auf Express abzuzielen (verständlich, da es begrenzt ist ).

Ich verwende VS 2010 Express unter Win 7 Prof. und es möchte immer v7.0A des Win SDK verwenden (das nicht alle erforderlichen Exes enthält), und es spielt keine Rolle, welche Version ich explizit als aktuell verwendet habe WindowsSdkVer.exe (Es wird weiterhin berichtet, dass die aktuelle Version des SDK festgelegt wurde, jedoch für VS 2008, obwohl nur 2010 Ex installiert ist.)

Meine billige Problemumgehung bestand darin, das WIN SDK v7.0 (oder eine andere Version wie v7.1) zu installieren und dann den Dateisystemordner in v7.0A umzubenennen - im Grunde habe ich nur VS 2010 Express angelogen, aber es funktioniert jetzt!


5

Eines Ihrer Projekte verwendet sgen.exe (Server Generator), um einen Webdienst zu generieren. Sie müssen SDKs installieren, um Server zu erstellen, oder Webdienstreferenzen aus dem Projekt entfernen.


1
Oder setzen Sie "Serialisierungsassembly generieren: Aus" auf der Registerkarte "Erstellen" der Projekteigenschaften des Webdienstes.
Samneric

1
GOTCHA: Wenn Sie es auf der Registerkarte "Build" deaktivieren, stellen Sie sicher, dass Sie dies für die relevante Build-Konfiguration tun (DropDown oben auf der Registerkarte "Build"). In meinem Fall war es nur der Build-Server mit dem Problem, also musste ich Ändern Sie dies in der 'Release'-Konfiguration.
Myster

4

Ich vermute, dass die Zieldatei den Werkzeugpfad überschreibt. Ich habe einen kurzen Blick in diese Datei geworfen und setze den SDKToolsPath unter einigen der dortigen Ziele auf $ TargetFrameworkSDKToolsDirectory. Ich denke nicht, dass Sie diese ohnehin in der Umgebung einstellen müssen, aber sie müssen möglicherweise in Ihren Projektdateien korrigiert werden.

Beachten Sie, dass laut dieser Seite http://nant.sourceforge.net/ Nant .Net 4.0 nicht unterstützt. Könnte dies das eigentliche Problem sein?

Entschuldigung, ich weiß, dass dies Ihre Frage nicht wirklich beantwortet :(


Richtig, NAnt unterstützt die Projekt- / Lösungsdateiformate für VS2010 noch nicht, weshalb ich MSBuild für den eigentlichen Kompilierungsschritt anrufe. Überprüft die Zieldatei.
Scott Mayfield

4

Ich hatte das gleiche Problem auf einem brandneuen Windows 10-Computer. Mein Setup:

  • Windows 10
  • Visual Studio 2015 installiert
  • Windows 10 SDK

Ich konnte jedoch keine .NET 4.0-Projekte erstellen:

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

Lösung: Nachdem ich versucht hatte (und fehlgeschlagen war), das Windows 7 SDK zu installieren (da dies auch das .NET 4.0 SDK umfasst), musste ich das Windows 8 SDK installieren und sicherstellen, dass das ".NET Framework 4.5 SDK" installiert ist.

Es ist verrückt ... aber es hat funktioniert.


Das hat mir auch unter Windows 10 genau geholfen.
Bourbert

3

Sie haben SDK Version 7.0A nicht installiert? Das ist ein Problem, das Sie beheben müssen. Sehen Sie in den VS2010-Installationsprotokolldateien nach, was schief gelaufen ist. Das SDK sollte in c: \ Programme \ Microsoft SDKS \ Windows \ 7.0a vorhanden sein, und der aufgeführte Registrierungsschlüssel muss ebenfalls vorhanden sein. Das Ausführen mit der 6.0a-Version von sgen.exe ist nicht in Ordnung, es muss jedoch der falsche Compiler verwendet werden.


1
Denken Sie daran, dass dies ein Build-Server ist. Daher war die Installation der vollständigen VS2010-Umgebung nicht meine erste Wahl. Ich konnte keinen verfügbaren Download des Windows SDK 7.0a
Scott Mayfield

3
Ich sehe das Problem nicht. Das Ausführen eines Builds auf einem Computer, dessen Konfiguration nicht mit den Entwicklungsmaschinen übereinstimmt, ist ein Problem, das Sie schnell zermürben wird.
Hans Passant

3

Legen Sie fest, Sdk40ToolsPathanstatt SdkToolsPatheinen anderen Speicherort als das Installationsverzeichnis anzugeben.

Ich habe ein ähnliches Problem mit AL.exe festgestellt, weil ich die Tools gerade auf den Build-Computer kopiert hatte, anstatt das SDK zu installieren, sodass die üblichen Registrierungsschlüssel fehlten. Ich habe einen Build mit Diagnoseausgabe (/ Verbosity: Diagnostic) ausgeführt und festgestellt, dass mehrere SDK-Toolpfade definiert wurden: Sdk40ToolsPath, Sdk35ToolsPath und SdkToolsPath. Wenn Sie Sdk40ToolsPath so einstellen, dass es auf den bin-Ordner der entsprechenden SDK-Version verweist, wurde das Problem für mich behoben.


Wo haben Sie Sdk40ToolsPath eingestellt?
Michael Freidgeim

Ich würde annehmen, dass es dem Umgebungspfad hinzugefügt werden muss. Bei mir hat es jedoch nicht funktioniert.
Timothy Lee Russell

Es tut mir leid, dass ich die Details vor so langer Zeit vergessen habe, aber ich denke, es war entweder eine Umgebungsvariable oder sie wurde in der MSBuild-Projektdatei festgelegt. Beachten Sie auch, dass sich die ursprüngliche Frage auf .NET Framework 4.0 / VS2010 bezieht, für spätere Framework-Versionen jedoch möglicherweise andere Variablen erforderlich sind.
IanS

2

Ich stimme der Antwort von IanS zu. Sie müssen kein neues SDK installieren. Stellen Sie einfach sicher, dass die Registrierungsschlüsselwerte SDK35ToolsPath und SDK40ToolPath für MSBuild auf die richtigen Registrierungsschlüsselwerte verweisen.

In meinem Fall war mein Projekt auf .NET 3.5 ausgerichtet und ich musste SDK35ToolsPath für den Schlüssel HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 auf $ setzen (Registrierung: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v6.0A \ WinSDKNetFxTools @ InstallationFolder). Und alles hat funktioniert.


2

Wir haben einen WinXP-Build-PC und verwenden Visual Build Pro 6, um unsere Software zu erstellen. Da einige unserer Entwickler VS 2010 verwenden, enthalten die Projektdateien jetzt einen Verweis auf "Tool Version 4.0". Soweit ich das beurteilen kann, muss Visual Build irgendwo eine sdk7.x finden, obwohl wir nur für .NET 3.5 erstellen . Dies führte dazu, dass lc.exe nicht gefunden wurde. Ich habe versucht, es zu täuschen, indem ich alle Makros auf das 6.0A-SDK verwies, das mit VS2008 geliefert wurde, das auf dem PC installiert ist, aber das hat nicht funktioniert.

Ich habe es schließlich zum Laufen gebracht, indem ich SDK 7.1 heruntergeladen und installiert habe. Ich habe dann einen Registrierungsschlüssel für 7.0A erstellt und den Installationspfad auf den Installationspfad des 7.1 SDK verwiesen. Jetzt findet es glücklich eine kompatible "lc.exe" und der gesamte Code wird gut kompiliert. Ich habe das Gefühl, dass ich jetzt auch .NET 4.0-Code kompilieren kann, obwohl VS2010 nicht installiert ist, aber das habe ich noch nicht versucht.


2

ToolsVersion = "4.0" erledigt das für mich in meinem MSBuild-Projekt:

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

Nun, in meinem Fall habe ich ToolsVersion = "14.0" für VS 2015 verwendet und dies hat das Problem gelöst
AndrewSilver

2

Stellen Sie zunächst sicher, dass Sie dotNetFx40_Full_x86_x64.exe bereits heruntergeladen und installiert haben (es ist normalerweise mit Visual Stdio verbunden).

Stellen Sie dann schnell neue Umgebungsvariablen unter Systemvariablen ein. Wie unten: "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.


Dies löst das Problem. Nur ein Hinweis, wenn jemand das gleiche Problem wie ich hat. Die Env-Variable muss TargetFrameworkSDKToolsDirectory und nicht SdkToolsPath heißen !!!
Markus

1

Ich hatte das gleiche Problem und hatte Windows SDK 7.0 und Windows SDK 7.1 installiert, wodurch das Problem nicht behoben wurde. Die Ursache des Problems war für mich, dass die fehlerhafte Klassenbibliothek mit Target Framework von .NET Framework 2.0 erstellt wurde.

Ich habe es in .NET Framework 4.0 geändert und lokal gearbeitet. Beim Einchecken auf dem Build-Server wurde es erfolgreich erstellt.


1

Ich hatte ein ähnliches Problem, insbesondere fehlgeschlagene msbuild: MSB3086, MSB3091: "AL.exe", "resgen.exe" nicht gefunden

Auf einem 64-Bit-Windows 7-Computer habe ich .NET Framework 4.5.1 und Windows SDK für Windows 8.1 installiert.

Obwohl die Einstellungen für das SDK besagten, dass es auf dem neuesten Stand war, war dies wahrscheinlich nicht der Fall. Ich habe das Problem gelöst, indem ich alle installierten Versionen des SDK entfernt und dann die folgenden in dieser Reihenfolge installiert habe:

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

Kurze Antwort: In der .csproj-Datei gibt es eine Möglichkeit, den Pfad zu sgen.exe mithilfe von SGenToolPath anzugeben:

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

Ihr Pfad mag unterschiedlich sein, aber SGenToolPath ist das, was Sie wollen.

Eine Liste anderer gängiger MSBuild Project-Eigenschaften finden Sie unter: https://msdn.microsoft.com/en-us/library/bb629394.aspx

Wir haben diese SGenToolPath-Einstellung in der .csproj-Datei verwendet, anstatt die Registrierungswerte auf dem Build-Server zu bearbeiten. Das Bearbeiten der Registrierungswerte auf meinem lokalen Computer hatte ebenfalls funktioniert, war jedoch etwas komplizierter und wir wollten uns nicht mit der Registrierung auf dem Build-Server herumschlagen.

Für die Registrierung: In diesem Fall bestand das Problem darin, dass die SDK40ToolsPath (s) unter HKLM \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild auf einen Registrierungswert $ (Registrierung: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v8.0A) verweisen \ WinSDK-NetFx40Tools-x86 @ InstallationFolder), die nicht vorhanden waren. Ich habe das gerade direkt durch den eigentlichen Pfad ersetzt.


1

Auch ich bin auf dieses Problem gestoßen, als ich versucht habe, mit Visual Studio 2017 ein Plugin auf meinem schrecklich durcheinandergebrachten Arbeitsplatzcomputer zu erstellen. Wenn Sie im Internet nach "resgen.exe kann nicht gefunden werden" suchen, finden Sie all diese Ratschläge, die wie " Verwenden Sie einfach regedit, um Ihre Windows-Registrierung zu bearbeiten und hier einen neuen Schlüssel zu erstellen und den Inhalt dieses Ordners zu kopieren und einzufügen." dieser andere Ordner, bla bla bla.'

Ich habe Wochen damit verbracht, meine Windows-Registrierung mit regedit durcheinander zu bringen, wahrscheinlich ein Dutzend Unterschlüssel hinzugefügt und ResGen.exe in viele verschiedene Verzeichnisse kopiert, manchmal in einem 'bin'-Ordner abgelegt, manchmal nur im Hauptordner. etc.

Am Ende wurde mir klar: "Hey, wenn Visual Studio eine detailliertere Fehlermeldung geben würde, wäre nichts davon ein Problem." Um weitere Details zu dem Fehler zu erhalten, habe ich MSBuild.exe direkt in meiner * .csproj-Datei über die Befehlszeile ausgeführt:

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

Natürlich müssen Sie die Pfaddetails an Ihre Situation anpassen, aber stellen Sie sicher, dass Sie 1) den vollständigen Pfad zu MSBuild.exe 2) den vollständigen Pfad zu Ihrer * .csproj-Datei 3) das -fl -flp: logfile = part, der MSBuild anweist, eine Protokolldatei für jeden Schritt zu erstellen, den es in diesem Prozess ausgeführt hat, 4) den Speicherort, an dem die * .log-Datei gespeichert werden soll, und 5) verbosity = diagnost, der MSBuild im Grunde nur mitteilt um Tonnen von Details in die * .log-Datei aufzunehmen.

Danach schlägt der Build wie immer fehl, es bleibt jedoch eine * .log-Datei übrig, die genau anzeigt, wo MSBuild nach Ihrer ResGen.exe-Datei gesucht hat. In meinem Fall habe ich am Ende der * .log-Datei Folgendes gefunden:

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"

Im Grunde genommen suchte MSBuild in fünf separaten Verzeichnissen nach ResGen.exe und gab dann auf. Dies ist die Art von Detail, die Sie aus der Visual Studio-Fehlermeldung einfach nicht erhalten können, und sie löst das Problem: Verwenden Sie einfach regedit, um einen Schlüssel für einen dieser fünf Speicherorte zu erstellen , und geben Sie den Wert "InstallationFolder" in den Schlüssel ein Dies sollte auf den Ordner verweisen, in dem sich Ihre ResGen.exe befindet (in meinem Fall "C: \ Programme \ Microsoft SDKs \ Windows \ v10.0A \ bin \ NETFX 4.7.2 Tools").

Wenn Sie ein Geisteswissenschaftler wie ich sind und keinen Hintergrund in Computern haben, könnten Sie versucht sein, einfach die Hölle aus Ihrer Windows-Registrierung heraus zu bearbeiten und ResGen.exe überall zu kopieren und einzufügen, wenn ein Fehler wie dieser auftritt natürlich schlechte Praxis). Befolgen Sie die oben beschriebenen Schritte: 1) Führen Sie MSBuild.exe direkt in Ihrer * .csproj-Datei aus, um den genauen Speicherort von MSBuild für ResGen.exe zu ermitteln. 2) Bearbeiten Sie Ihre Windows-Registrierung genau, damit MSBuild ResGen finden kann. exe.


Ich habe es versucht, aber aus irgendeinem Grund wird die Liste der angezeigten Pfade nicht angezeigt. Ich habe einen ähnlichen Beitrag wie Ihren auf dieser Website gefunden: community.sdl.com/developers-more/developers/…, damit ich weiß, dass er funktionieren sollte, aber ohne Erfolg. Welche Version von MSBuild verwenden Sie?
user11809641

Sieht so aus, als würde ich MSBuild Version 4.0.30319 verwenden. Ich habe auch Version 3.5, 3.0 und 2.0.50727 auf diesem Computer installiert. Ich habe versucht, diese Versionen von MSBuild in meiner * .csproj-Datei auszuführen (auf die gleiche Weise wie oben beschrieben), aber es hat nicht funktioniert ... ich habe nicht einmal eine * .log-Datei erstellt. /// Wenn Sie MSBuild für Ihre * .csproj-Datei ausführen, erstellt der Computer mindestens eine * Protokolldatei? Meines Wissens nach gibt es eine Protokolldatei, nur keine spezifischen Informationen zu den Pfaden, die bei der Suche nach ResGen.exe durchsucht wurden - ist das richtig?
Todbott

Sieht so aus, als hätte ich dieselbe Version von MSBuild (4.0.30319). Und ja, du hast recht. Ich erhalte eine Protokolldatei, die jedoch keine Informationen zu Registrierungspfaden enthält. Welchen der fünf Pfade, die Sie oben gepostet haben, haben Sie letztendlich verwendet?
user11809641

Ich habe den ersten Pfad in der Liste verwendet - habe gerade einen "Installationsordner" im Schlüssel SOFTWARE \ WOW6432Node \ Microsoft \ Microsoft SDKs \ NETFXSDK \ 4.6.2 \ WinSDK-NetFx40Tools-x86 hinzugefügt. Außerdem ist die * .log-Datei tatsächlich extrem lang - in meinem Fall Tausende von Zeilen. Ich konnte die Pfadinformationen mit meinem bloßen Auge nicht finden. Am Ende öffnete ich die * .log-Datei im Editor und suchte nach "ResGen.exe", wodurch ich auf den entsprechenden Bereich (Pfadinformationen) aufmerksam wurde.
Todbott

1
Super - Glückwunsch! Sie sind einer von wenigen Leuten geworden (ein paar hundert, würde ich vermuten), die sich durch die Fehler und Rätsel gekämpft und tatsächlich erfolgreich ein Plugin für Trados kompiliert haben. Viel Glück beim Veröffentlichen Ihres Plugins, wir sehen uns im SDL Appstore!
Todbott

1

Ich habe es behoben, indem ich dies als Befehlszeilenparameter an msbuild.exe übergeben habe:

Ihr Kilometerstand hängt von der SDK-Version Ihres Systems ab

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

0

Neben den Registrierungsmods müssen Sie möglicherweise die Version des .net-SDK ändern, auf die Ihre Einstellungen in Visual Studio eingestellt sind.

Ich hatte dieses Problem und beschloss, die Projekt-Debug-Einstellungen zu überprüfen.

Projekt => Eigenschaften der Symbolleiste => Schaltfläche Erweiterte Kompilierungsoptionen debuggen

Das Ziel-Framework (alle Konfigurationen) wurde auf 3.0 festgelegt, was sich nicht auf meinem System befindet.

Ich habe das in 4.0 geändert und musste dann das Projekt und Visual Studio 2010 neu starten.

Das Projekt wurde dann fehlerfrei erstellt und ausgeführt.


Ich habe einen Fehler gemacht. Projekt => Eigenschaften der Symbolleiste => Erweiterte Kompilierungsoptionen kompilieren Ich habe auch ein neues Projekt erstellt und das neue Projekt .net wurde auf 3.0 gesetzt. Daher muss auch die Standardeinstellung geändert werden. Scott A. Tovey
Scott Tovey

Ich habe herausgefunden, dass beim Erstellen eines Projekts oben im Fenster eine Dropdown-Liste aller Frameworks angezeigt wird. Alles wird aufgelistet, unabhängig davon, ob es installiert ist oder nicht. Sobald Sie ein Framework ausgewählt und ein Projekt aus dieser Liste erstellt haben, bleibt es die Standardeinstellung, bis Sie es für ein neues Projekt in ein anderes Framework ändern. Dies ist etwas rücksichtslos. Die Liste sollte nur Frameworks enthalten, die auf dem System installiert sind.
Scott Tovey

0

Ich hatte ein ähnliches Problem. Ich hatte ein Projekt mit erstellt Visual Studio 2010und bekam dann den obigen Fehler, als ich es mit kompilierte Visual Studio 2012. Ich habe einfach den gesamten Inhalt von C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0Ain kopiert C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0Aund das hat mein Problem gelöst.


3
Ich wünschte, es gäbe eine Abstimmung für die schlechteste Lösung der Welt. Das wäre es.
Jonypony3

0

Ich hatte gerade diesen Fehler mit einer SLN-Datei, die ursprünglich in Visual Studio 2010 erstellt wurde (und von Visual Studio 2010 und TFS 2010 erstellt wurde). Ich hatte die Lösungsdatei so geändert, dass KEIN Projekt erstellt wurde, das nicht in einer bestimmten Konfiguration erstellt werden sollte, und Visual Studio änderte den Header der Lösungsdatei von:

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

Zu:

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

Das Zurücksetzen auf die ursprüngliche Version 2010 hat mein Problem behoben. Ich denke, die Abwärtskompatibilität in Visual Studio wurde immer noch nicht perfektioniert.


0

Versuchen Sie es mit der "Reparatur" von Visual Studio. Es hat bei mir funktioniert.


0

CMD-Wrapper
Ich habe all das Zeug von hier und noch mehr ausprobiert. Nichts hat mir geholfen.

Ich habe CMD-Wrapper für MSBuild und DevEnv.com angewendet.
Die Hauptidee eines solchen Wrappers besteht darin, eine vorbereitete Umgebung durch Aufrufen von Eingabeaufforderungen aus Visual Studio zu erstellen. Übergeben Sie dann die Standardeingabeparameter an einen Aufruf von MSBuild oder DevEnv.com.

Auf meinem Build-Server kann ich jetzt Projekte aus verschiedenen Visual Studio-Versionen erstellen.

Verwendung
Ich musste Aufrufe von MSBuild und DevEnv durch einen Aufruf meiner Batch-Datei-Wrapper ersetzen.
Und ich habe keine Eingabeparameter geändert. Als Beispiel für meinen MSBuild-Wrapper-Aufruf:

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

Fertige Lösung
Tatsächlich hatte ich viel mehr Probleme mit einer Migration von VS 2010 zu VS 2015. Aber diese war die erste und die schwierigste.
Mein bescheidenes Rettungsrezept für einen Build Server ist hier. Möglicherweise ist es schwierig, diesen ganzen CMD-Stil dort vom ersten Moment an zu verstehen, aber ich hoffe, dass jede Logik offensichtlich ist.

Hinweise
Es gibt
MSBuild Command Prompt for Visual Studiound Developer Command Prompt for Visual Studio
ich verwende sie entsprechend für MSBuild und DevEnv.com. Aber wahrscheinlich wird die MSBuild-Eingabeaufforderung ausreichen.

Für VS 2015 sind diese Eingabeaufforderungen hier C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\. Oder schauen Sie durch das Windows-Programmmenü.

Um alle Eingabeparameter in einer von mir verwendeten Batchdatei an MSBuild oder DevEnv zu übergeben CALL MSBuild %*

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.