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.
Da Sie das neueste SDK installiert haben (ich gehe davon aus, dass dies v7.1 ist)
- Gehen Sie im Startmenü zu "Microsoft Windows SDK v7.1"
- Wählen Sie "Windows SDK 7.1-Eingabeaufforderung" und geben Sie ein
cD-Setup
WindowsSdkVer -version: v7.1
Dadurch wird msbuild angewiesen, diese Version der Tools zu verwenden, ohne dass eine unheimliche Bearbeitung der Registrierung erforderlich ist.
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.
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])"
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])
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.
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.
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
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.