MSBuild на CI Server не может найти AL.exe
У меня проблема на моем сервере сборки TeamCity CI, где во время компиляции я получаю следующую ошибку:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319 \ Microsoft.Common.targets (2342, 9): ошибка MSB3086: Задаче не удалось найти "AL.exe" с помощью SdkToolsPath "или ключ реестра"HKEY_LOCAL_MACHINE\ " ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ \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.
8 ответов
Как вы установили последний SDK (я полагаю, что это v7.1)
- Перейдите к "Microsoft Windows SDK v7.1" из меню "Пуск".
- Выберите "Командная строка Windows SDK 7.1" и введите
Настройка CD
WindowsSdkVer -версия:v7.1
Это скажет msbuild использовать эту версию инструментов без необходимости какого-либо страшного редактирования реестра.
Несмотря на то, что вопрос довольно старый, но он все еще отображается в верхней части результатов поиска 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 не требуется.
Вам также необходимо применить следующее исправление реестра, чтобы обновить 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)"
Следуйте приведенным ниже инструкциям. Это отлично сработало для меня. Сэкономил мое время.
1- Щелкните правой кнопкой мыши значок " Мой компьютер" и выберите " Свойства" или на панели управления Windows выберите " Система".
2- Выберите Расширенные настройки системы.
3- На вкладке " Дополнительно " щелкните " Переменные среды".
4- Нажмите " Создать", чтобы создать новую переменную среды в разделе " Пользовательские переменные".
5- Имя переменной: TargetFrameworkSDKToolsDirectory
6- Значение переменной: TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools
Значение переменной зависит от пути установки вашего SDK.
7- Нажмите OK и сохраните все окна.
8- Перезапустите Visual Studio.
У меня была такая же проблема, вот мой простой ответ на это.
После того, как вы установите 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)
У меня есть простое, эффективное решение.
Проблема заключается в том, что версия инструментов, поставляемая с 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 \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v7.1"
Работа выполнена. MSBuild теперь отлично работает на сервере TeamCity.
Добавить систему env. переменная TargetFrameworkSDKToolsDirectory
как это:
TargetFrameworkSDKToolsDirectory = C: \ Program Files (x86) \ Microsoft SDKs \ Windows \ v10.0A \ bin \ NETFX 4.6.2 Инструменты
перезапустить VS
Столкнулся с той же проблемой при настройке нового сервера сборки в Windows 10. Найден и установлен самый последний (на тот момент) Microsoft Windows SDK для Windows 7 и.NET Framework 4, и это решило проблему.
Недавно мы столкнулись с этой проблемой, пытаясь заставить работать наши сборки.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 искать подходящее место для инструментов, даже взламывая реестр.