web-dev-qa-db-de.com

MSBuild auf CI Server kann AL.exe nicht finden

Ich habe ein Problem auf meinem TeamCity CI-Build-Server, bei dem beim Kompilieren die folgende Fehlermeldung angezeigt wird:

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (2342, 9): Fehler MSB3086: Task "AL.exe" konnte nicht gefunden werden, indem der SdkToolsPath "" oder der Registrierungsschlüssel "HKEY_LOCAL_MACHINE \" verwendet wurde. SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A ". Stellen Sie sicher, dass der SdkToolsPath festgelegt ist und das Tool an der richtigen prozessorspezifischen Position unter dem SdkToolsPath vorhanden ist und dass das Microsoft Windows SDK installiert ist 

Ich habe ähnliche Berichte von vor einem Jahr gefunden, als Leute ein Upgrade auf .NET 3.5 vorgenommen haben, zum Beispiel this . In diesem Fall konnte durch die Installation des neuesten SDK das Problem behoben werden. Ich habe jedoch bereits das neueste SDK ( Microsoft Windows SDK für Windows 7 und .NET Framework 4 ) auf meinem Build-Server installiert. Die MSBuild-Tools befinden sich alle auf dem Server in einem Ordner namens

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319 

und AL.exe existiert in 

C:\Programme\Microsoft SDKs\Windows\v7.1\Bin\NETFX 4.0 Tools 

Der in der Fehlermeldung angegebene Registrierungsschlüssel ist jedoch nicht vorhanden. Anscheinend stimmt die Installation/Konfiguration von MSBuild nicht. Dieser Fehler tritt nur bei Projekten auf, die über eingebettete Ressourcen verfügen, für die AL.exe erforderlich ist.

44
Tim Long

Da Sie das neueste SDK installiert haben (ich gehe davon aus, dass dies v7.1 ist)

  1. Gehen Sie im Startmenü zu "Microsoft Windows SDK v7.1"
  2. Wählen Sie "Windows SDK 7.1-Eingabeaufforderung" und geben Sie ein
  3. cD-Setup

  4. WindowsSdkVer -version: v7.1

Dadurch wird msbuild angewiesen, diese Version der Tools zu verwenden, ohne dass eine unheimliche Bearbeitung der Registrierung erforderlich ist.

52
AndyPook

Auch wenn die Frage schon recht alt ist, sie immer noch oben in den Suchergebnissen von Google erscheint, entschied ich mich, meine Lösung ebenfalls zu veröffentlichen. Ich bin während des TeamCity-Setups unter Windows Server 2016 und Windows 10 Pro in dasselbe Problem geraten.

Ich habe Microsoft Build Tools 2015 und Windows 10 SDK (Nur Tools für .NET 4.6.2) installiert und den Fehler aus der Frage erhalten.

Das fehlende Puzzle bestand darin, die Umgebungsvariable zu setzen: TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools.

Nach dem Festlegen der Umgebungsvariablen konnte MSBuild alle benötigten Tools einschließlich AL.exe auflösen und das Erstellen war erfolgreich.

Bitte lassen Sie mich wissen, ob dies durch das Setzen von Werten in der Registrierung erreicht werden kann. Ansonsten funktionieren Umgebungsvariablen auch in diesem Fall sehr gut und es ist keine Installation von VS erforderlich.

14
Andrii Litvinov

Sie müssen auch das folgende Registrierungs-Update anwenden, um msbuild so zu aktualisieren, dass es auf die sdk-Werte der Version 7.1 verweist.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0]
"MSBuildToolsPath"="C:\\WINDOWS\\Microsoft.NET\\Framework\\v4.0.30319\\"
"MSBuildToolsRoot"="C:\\WINDOWS\\Microsoft.NET\\Framework\\"
"FrameworkSDKRoot"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\[email protected])"
"MSBuildRuntimeVersion"="4.0.30319"
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\[email protected])"
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\[email protected])"
"MSBuildToolsPath32"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MSBuild\\ToolsVersions\\[email protected])"
6
Taliesin

Ich hatte dort das gleiche Problem, hier ist meine einfache Antwort darauf.

Nachdem Sie das Microsoft Windows SDK 7.1 auf dem TeamCity Server installiert haben.

In Regedit diesen Schlüssel ändern  

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\SDK40ToolsPath

zu 

$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\[email protected])
4
poolfoot

Ich habe eine einfache, effektive Lösung.

Das Problem scheint zu sein, dass die mit Visual Studio gelieferte Werkzeugversion die Version 7.0A ist, während die mit dem Windows SDK gelieferte Version die Version 7.1 ist. Das ist alles sehr gut, aber MSBuild.exe sucht immer noch nach den Registrierungsschlüsseln der Version 7.0A, die nicht existieren. Das muss ein Fehler sein!

In meiner Registrierung sind alle Informationen für V6.0 und V7.1 vorhanden und korrekt. Meine Lösung ist also einfach. Ich habe einen Registrierungslink erstellt, der einen Alias ​​der 7.1-Schlüssel macht.

Es ist nicht möglich, Registrierungslinks mit den integrierten Tools zu erstellen. Daher habe ich ein kleines Dienstprogramm namens 'regln' von here heruntergeladen.

C:> regln-x86.exe "\ Registry\Machine\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A"\Registry \Machine\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1 "

Job erledigt. MSBuild funktioniert jetzt perfekt auf dem TeamCity-Server.

3
Tim Long

Das gleiche Problem wurde beim Einrichten eines neuen Build-Servers unter Windows 10 .. festgestellt. Das neueste (zur Zeit) Microsoft Windows SDK für Windows 7 und .NET Framework 4 wurde gefunden und installiert.

1
Ryan_S

Systemumgebung hinzufügen. Variable TargetFrameworkSDKToolsDirectory

so was:

TargetFrameworkSDKToolsDirectory = C:\Programme (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools

vS neu starten

0
Altivo

Wir hatten kürzlich dieses Problem beim Versuch, unsere .NET 4.0-Builds zum Laufen zu bringen. Wir fanden heraus, dass sich der Speicherort von al.exe zwischen dem ursprünglichen Format von MSBuild mit .NET 4.0 und dem Visual Studio SDK für .NET 4.0 (das später veröffentlicht wurde) geändert hat.

Da die einzige Standalone-Installation der verfügbaren SDK-Tools diejenige ist, die wir bereits ohne Erfolg installiert hatten (die von Ihnen erwähnte), war die einzige Lösung, die wir uns vorstellen konnten, die Installation von Visual Studio auf den Build-Agenten. Wir haben Visual Studio 2010 Express (um die Installation so gering wie möglich zu halten) aufgesetzt, und das Problem ist behoben. Keine hübsche Lösung, aber es hat funktioniert - durch die Installation von VS2010 werden auch die SDK-Tools der jeweiligen Version installiert, nach der MSBuild zu suchen scheint.

Dies ist ein Problem, das eigentlich nicht passieren sollte, aber es schien nicht möglich zu sein, MSBuild an den richtigen Ort für die Tools zu suchen, nicht einmal in der Registry.

0
adrianbanks