MSBuild sur le serveur CI ne peut pas trouver AL.exe
J'ai un problème sur mon serveur de génération TeamCity CI où l'erreur suivante s'affiche lors de la compilation:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (2342, 9): erreur MSB3086: la tâche n'a pas pu trouver "AL.exe" à l'aide de SdkToolsPath "" ou de la clé de registre "HKEY_LOCAL_MACHINE \". LOGICIELS\Microsoft\Microsoft SDK\Windows\v7.0A ". Assurez-vous que SdkToolsPath est défini et que l'outil existe à l'emplacement approprié du processeur sous SdkToolsPath et que le Kit de développement logiciel (SDK) de Microsoft Windows est installé.
J'ai trouvé des rapports similaires à ceux d'il y a un an, lors de la mise à niveau vers .NET 3.5, par exemple celui-ci . Dans ce cas, l’installation du dernier SDK a résolu le problème, mais j’ai déjà installé le dernier SDK ( SDK Microsoft Windows pour Windows 7 et .NET Framework 4 ) sur mon serveur de génération. Les outils MSBuild sont tous présents sur le serveur, dans un dossier appelé
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319
et AL.exe existe dans
Outils C:\Program Files\Microsoft SDK\Windows\v7.1\Bin\NETFX 4.0
Toutefois, la clé de registre mentionnée dans le message d'erreur n'existe pas. Il semble donc y avoir un problème avec l’installation/configuration de MSBuild. Cette erreur ne survient que pour les projets comportant des ressources incorporées, qui nécessitent AL.exe.
Comme vous avez installé le dernier SDK (je suppose que c'est v7.1)
- Allez à "Microsoft Windows SDK v7.1" dans le menu Démarrer.
- Sélectionnez "Invite de commandes Windows SDK 7.1" et entrez
cd Setup
WindowsSdkVer -version: v7.1
Cela indiquera à msbuild d'utiliser cette version des outils sans avoir à faire une édition de registre effrayante.
Même si la question est assez ancienne mais qu'elle figure toujours en haut des résultats de recherche Google, j'ai décidé de publier également ma solution. J'ai été pris au piège dans le même problème lors de l'installation de TeamCity sous Windows Server 2016 et Windows 10 Pro.
J'ai installé Microsoft Build Tools 2015 et Windows 10 SDK (Outils uniquement pour .NET 4.6.2) et j'ai eu l'erreur de la question.
Le puzzle manquant consistait à définir la variable d'environnement: TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools.
Après avoir défini la variable d’environnement, MSBuild a pu résoudre tous les outils nécessaires, y compris AL.exe, et la construction a réussi.
Faites-moi savoir s'il est possible d'atteindre le même objectif en définissant des valeurs dans la base de registres. Sinon, les variables d'environnement fonctionnent également très bien dans ce cas et aucune installation de VS n'est nécessaire.
Vous devez également appliquer le correctif de registre suivant pour mettre à jour msbuild afin qu'il pointe vers les valeurs du sdk V7.1.
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\\v7.1@InstallationFolder)"
"MSBuildRuntimeVersion"="4.0.30319"
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\WinSDK-NetFx40Tools-x86@InstallationFolder)"
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\WinSDKNetFx35Tools@InstallationFolder)"
"MSBuildToolsPath32"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MSBuild\\ToolsVersions\\4.0@MSBuildToolsPath)"
J'ai eu le même problème là-bas, voici ma réponse simple à cela.
Après avoir installé le Kit de développement logiciel (SDK) Microsoft Windows 7.1 sur le serveur TeamCity.
In Regedit Changer cette clé
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\SDK40ToolsPath
à
$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx40Tools-x86@InstallationFolder)
J'ai une solution simple et efficace.
Le problème semble être que la version des outils livrée avec Visual Studio est la version 7.0A, tandis que la version livrée avec le SDK Windows est la version 7.1. C'est très bien, mais MSBuild.exe cherche toujours les clés de registre de la version 7.0A, qui n'existent pas. Cela doit être un bug!
En regardant dans mon registre, toutes les informations pour les versions 6.0 et 7.1 sont présentes et correctes. Donc ma solution est simple. J'ai créé un lien de registre qui fait un alias des clés 7.1.
Il n'est pas possible de créer des liens de registre à l'aide des outils intégrés. J'ai donc téléchargé un petit utilitaire appelé «regln» à partir de ici .
C:> regln-x86.exe "\ Registry\Machine\Logiciel\Microsoft\Microsoft SDK\Windows\v7.0A" "\ Registry \Machine\Logiciel\Microsoft\Microsoft SDK\Windows\v7.1"
Travail accompli. MSBuild fonctionne maintenant parfaitement sur le serveur TeamCity.
Couru dans le même problème la configuration d'un nouveau serveur de construction sur Windows 10 . Trouvé et installé le dernier (à l'époque) SDK Microsoft Windows pour Windows 7 et .NET Framework 4 et qui a résolu le problème.
Ajouter env système variable TargetFrameworkSDKToolsDirectory
comme ça:
TargetFrameworkSDKToolsDirectory = C:\Fichiers de programme (x86)\Microsoft SDK\Windows\v10.0A\bin\NETFX 4.6.2 Outils
redémarrer VS
Nous avons récemment eu ce problème en essayant de faire fonctionner nos versions .Net 4.0. Nous avons constaté que l'emplacement de al.exe avait changé entre l'emplacement où se trouvait le fichier MSBuild d'origine fourni avec .Net 4.0 et le SDK Visual Studio pour .Net 4.0 (publié ultérieurement).
Étant donné que la seule installation autonome des outils SDK disponible est celle que nous avions déjà installée sans succès (celle que vous avez mentionnée), la seule solution à laquelle nous pouvions penser était d'installer Visual Studio sur les agents de génération. Nous avons mis Visual Studio 2010 Express (pour que l'installation soit aussi légère que possible) et le problème a disparu. Ce n’était pas une belle solution, mais cela a fonctionné - l’installation de VS2010 installe également les outils SDK de la version spécifique que MSBuild semble rechercher.
C’est un problème qui ne devrait vraiment pas se produire, mais il ne semblait pas y avoir de moyen de faire en sorte que MSBuild cherche au bon endroit les outils, même en cherchant dans le registre.