MSBuild на CI Server не может найти AL.exe

Question

У меня проблема с сервером сборки 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 SDKs \ Windows \ v7.0A". Убедитесь, что SdkToolsPath установлен, и инструмент существует в правильном определенном месте процессора под SdkToolsPath, и что Microsoft Windows SDK установлен

Я нашел похожие отчеты за год назад, когда люди переходили на .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 SDKs \ Windows \ v7.1 \ Bin \ NETFX 4.0 Tools

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

Answer 1

Поскольку у вас установлена ​​последняя версия SDK (я полагаю, это v7.1)

1. Перейдите в «Microsoft Windows SDK v7.1» из меню «Пуск»
2. Выберите «Командная строка Windows SDK 7.1» и введите

3. Настройка CD

4. WindowsSdkVer-версия: v7.1

Это скажет msbuild использовать эту версию инструментов без каких-либо страшных изменений реестра.

Answer 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 не требуется.

Answer 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\\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)"

Answer 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\WinSDK-NetFx40Tools-x86@InstallationFolder)

Answer 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 SDKs \ Windows \ v7.0A" "\ Registry \ Machine \ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ \ Microsoft \ Microsoft SDK \ Windows \ v7.1 "

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

Answer 6

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

Answer 7

Добавить систему env.переменная TargetFrameworkSDKToolsDirectory

примерно так:

TargetFrameworkSDKToolsDirectory = C: \ Program Files (x86) \ Microsoft SDK \ Windows \ v10.0A \ bin \ NETFX 4.6.2 Tools

перезапустить VS

Answer 8

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

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

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