MSBuild на сервере CI не может найти AL.exe

У меня возникла проблема на моем сервере сборки TeamCity CI, где во время компиляции я получаю следующую ошибку:

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(2342, 9): ошибка MSB3086: задача не могла найти "AL.exe" с помощью SdkToolsPath "или раздел реестра" HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDK\Windows\v7.0A". Убедитесь, что SdkToolsPath установлен, и инструмент существует в правильном месте для конкретного процессора в SdkToolsPath и установлен SDK Microsoft Windows.

Я нашел похожие отчеты за год назад, когда люди обновлялись до .NET 3.5, например этот. В этом случае установка последней версии SDK решила проблему, однако я уже установил последнюю версию SDK (Microsoft Windows SDK для Windows 7 и .NET Framework 4) на моем сервере сборки. Средства MSBuild находятся на сервере, в папке с именем

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

и AL.exe существует в

C:\Program Files\Microsoft SDK\Windows\v7.1\Bin\NETFX 4.0 Tools

Однако раздел реестра, упомянутый в сообщении об ошибке, не существует. Таким образом, похоже, что что-то не так с установкой/конфигурацией MSBuild. Эта ошибка возникает только для проектов с встроенными ресурсами, для которых требуется AL.exe.

Ответ 1

Как вы установили последний SDK (я предполагаю, что v7.1)

Перейдите в "Microsoft Windows SDK v7.1" из меню "Пуск"

Выберите "Командная строка Windows SDK 7.1" и введите

cd Setup

WindowsSdkVer -version: v7.1

Это сообщит msbuild, чтобы использовать эту версию инструментов, не требуя какого-либо страшного редактирования реестра.

Ответ 2

Несмотря на то, что вопрос довольно старый, но он по-прежнему отображается в верхней части результатов поиска Google, поэтому я решил опубликовать свое решение. Я попал в одну и ту же проблему во время установки TeamCity в Windows Server 2016 и Windows 10 Pro.

Я установил Microsoft Build Tools 2015 и Windows 10 SDK (Только инструменты для .NET 4.6.2) и получил сообщение об ошибке.

Недопустимая головоломка заключалась в том, чтобы установить переменную среды: TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools.

После установки переменной окружения MSBuild смог разрешить все необходимые инструменты, включая AL.exe, и выполнить сборку.

Пожалуйста, дайте мне знать, если это может быть достигнуто путем установки значений в реестре, но в остальном переменные среды также работают очень хорошо в этом случае, и установка VS не требуется.

Ответ 3

Вам также необходимо применить следующее исправление реестра, чтобы обновить msbuild, чтобы указать значения 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\\[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])"

Ответ 4

У меня была такая же проблема, вот мой простой ответ на этот вопрос.

После установки Microsoft Windows SDK 7.1 на сервере TeamCity.

В Regedit Измените этот ключ

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

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

Посмотрите на картинку, я получил свой первый проект TeamCity Building с этим! (был v7.0a) У меня есть фотография, чтобы показать, как это было просто.

> Oops! Your picture couldn't be submitted because:
> 
> We're sorry, but as a spam prevention mechanism, new users aren't
> allowed to post images. Earn more than 10 reputation to post images.

Ответ 5

У меня есть простое, эффективное исправление.

Проблема заключается в том, что версия инструментов, поставляемая с Visual Studio, - это версия 7.0A, а версия, поставляемая с Windows SDK, - это версия 7.1. Все это очень хорошо, но MSBuild.exe по-прежнему ищет ключи реестра версии 7.0A, которых нет. Это должно быть ошибкой!

В моем реестре вся информация для V6.0 и V7.1 присутствует и правильная. Поэтому мое решение прост. Я создал ссылку реестра, которая делает псевдоним 7.1 ключей.

Невозможно создать ссылки на реестр с помощью встроенных инструментов, поэтому я загрузил небольшую утилиту под названием 'regln' из здесь.

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

Работа выполнена. MSBuild теперь отлично работает на сервере TeamCity.

Ответ 6

Включите эту же проблему, настроив новый сервер сборки на Windows 10. Нашел и установил последние (в то время) Microsoft Windows SDK для Windows 7 и .NET Framework 4, и это решило проблему.

Ответ 7

Недавно мы столкнулись с этой проблемой, пытаясь заставить наши сборки .Net 4.0 работать. Мы обнаружили, что местоположение al.exe изменилось между тем, где оригинальный MSBuild, который поставляется с .NET 4.0, и SDK Visual Studio для .Net 4.0 (который был выпущен позже).

Поскольку единственная автономная установка доступных инструментов SDK - это тот, который мы уже установили без успеха (тот, который вы упомянули), единственным решением, о котором мы могли подумать, было установить Visual Studio на агенты сборки. Мы размещаем Visual Studio 2010 Express (чтобы как можно меньше установить установку как можно более легкий), и проблема исчезла. Не очень красивое решение, но оно действительно работало - установка VS2010 также устанавливает инструменты SDK конкретной версии, которую MSBuild ищет.

Это проблема, которая действительно не должна произойти, но, похоже, не было способа заставить MSBuild выглядеть в правильном месте для инструментов, даже взломав в реестре.