MSBuild sur CI Server ne peut pas trouver AL.exe

J’ai un problème sur mon serveur de build TeamCity CI où, lors de la compilation, j’obtiens l’erreur suivante:

C: \ WINDOWS \ Microsoft.NET \ Framework \ v4.0.30319 \ Microsoft.Common.targets (2342, 9): erreur MSB3086: La tâche n’a pas trouvé “AL.exe” à l’aide de SdkToolsPath “” ou de la clé de registre “HKEY_LOCAL_MACHINE \ LOGICIEL \ Microsoft \ Microsoft SDKs \ Windows \ v7.0A “. Assurez-vous que SdkToolsPath est défini et que l’outil existe dans l’emplacement approprié du processeur sous SdkToolsPath et que le Kit de développement Microsoft Windows est installé

J’ai trouvé des rapports similaires il y a un an lorsque les gens passaient à .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 ( Microsoft Windows SDK 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

C: \ Program Files \ Kit de développement Microsoft \ Windows \ Outils v7.1 \ Bin \ NETFX 4.0

Cependant, la clé de registre mentionnée dans le message d’erreur n’existe pas. Donc, il semble qu’il y ait quelque chose qui ne va pas avec l’installation / configuration de MSBuild. Cette erreur se produit uniquement pour les projets dotés de ressources incorporées nécessitant AL.exe.

Comme vous avez installé le dernier SDK (je suppose que c’est la v7.1)

  1. Allez dans “Microsoft Windows SDK v7.1” dans le menu Démarrer
  2. Sélectionnez “Invite de commandes du SDK Windows 7.1” et entrez
  3. cd Setup

  4. WindowsSdkVer -version: v7.1

Cela indiquera à msbuild d’utiliser cette version des outils sans avoir à faire de modification de registre effrayante.

Même si la question est assez ancienne mais elle apparaît toujours en tête des résultats de recherche Google, j’ai donc décidé de poster ma solution. Je suis coincé dans le même problème lors de la configuration de TeamCity sur Windows Server 2016 et Windows 10 Pro.

J’ai installé Microsoft Build Tools 2015 et Windows 10 SDK (uniquement des outils pour .NET 4.6.2) et j’ai reçu l’erreur de la question.

Le casse-tête 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 été capable de résoudre tous les outils nécessaires, y compris AL.exe, et la génération a réussi.

S’il vous plaît laissez-moi savoir si la même chose peut être obtenue en définissant des valeurs dans le registre, mais 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 de pointer vers les valeurs 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é Microsoft Windows SDK 7.1 sur le serveur TeamCity.

Dans Regedit Modifier 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 un correctif simple et efficace.

Le problème semble être que la version des outils fournie avec Visual Studio est la version 7.0A, tandis que la version fournie avec le SDK Windows est la version 7.1. C’est très bien, mais MSBuild.exe recherche 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 V6.0 et V7.1 sont présentes et correctes. Donc, ma solution est simple. J’ai créé un lien de registre qui crée 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 là .

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

Travail terminé. MSBuild fonctionne désormais parfaitement sur le serveur TeamCity.

Le même problème est survenu lors de la configuration d’un nouveau serveur de génération sous Windows 10. Nous avons trouvé et installé le dernier (à l’époque) Microsoft Windows SDK pour Windows 7 et .NET Framework 4 et résolu le problème.

Nous avons récemment eu ce problème en essayant de faire fonctionner nos builds .Net 4.0. Nous avons constaté que l’emplacement d’al.exe avait changé entre le MSBuild d’origine fourni avec .Net 4.0 et le Visual Studio SDK pour .Net 4.0 (publié ultérieurement).

Comme la seule installation autonome des outils SDK disponibles est celle que nous avions déjà installée sans succès (celle que vous avez mentionnée), la seule solution envisageable consistait à installer Visual Studio sur les agents de génération. Nous avons mis Visual Studio 2010 Express (pour que l’installation rest aussi légère que possible) et le problème a disparu. Ce n’est pas une solution intéressante, 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 recherche au bon endroit les outils, même en contournant le registre.