Beim Ausführen von MSBuild kann SDKToolsPath nicht gelesen werden

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

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.

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.

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

msbuild.exe /p:GenerateSerializationAssemblies=Off

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"

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.

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!

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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

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

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.

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

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