При запуске MSBuild не удается прочитать SDKToolsPath
Привет, у меня возникла небольшая проблема с запуском сценария NAnt, который использовался для правильной сборки моего веб-сайта на основе.Net 2.0 при компиляции с VS2008 и связанными с ним инструментами. Недавно я обновил все файлы проекта / решения до VS2010, и теперь моя сборка завершается с ошибкой:
[exec] C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Microsoft.Common.targets (2249,9): ошибка MSB3086: Задаче не удалось найти "sgen.exe" с помощью S dkToolsPath "или реестра ключ "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A". Убедитесь, что SdkToolsPath установлен, и инструмент существует в правильном определенном месте процессора под SdkToolsPath, и что Microsoft Windows SDK установлен
Теперь у меня действительно есть предыдущие версии (.Net 3.5) Windows SDK, установленные на сервере сборки, и установлена полная платформа.Net 4.0, но я не сталкивался с конкретной версией Windows SDK для.Net 4.0.
После небольшого количества экспериментов и исследований я, наконец, просто установил новую переменную окружения "SDKToolsPath" и указал ее на копию sgen.exe в моей папке Windows 6.0 SDK. Это вызвало ту же ошибку, но заставило меня заметить, что хотя переменная окружения SDKToolsPath установлена (подтверждено, что я могу "вывести" ее в командной строке, и она имеет ожидаемое значение), сообщение об ошибке, похоже, указывает, что не читается (обратите внимание на пустые кавычки).
Большая часть информации, которую я нашел, относится к.Net 3.5 (или более ранней версии). Не много 4.0 связано там еще. Поиск кода ошибки MSB3086 также не принес ничего полезного. Есть идеи, что это может быть?
Скотт
23 ответа
Мне пришлось прикусить пулю и установить VS 2010 на наш сервер сборки, чтобы решить эту проблему. Насколько я вижу, в MSDN нет ни одной версии Windows SDK 7.0A. Тем не менее, установка VS 2010, кажется, устанавливает его, создавая regkey 7.0A и папку 7.0A в Program Files \ Microsoft SDKs\Windows.
Я не мог поставить Visual Studio на сервере сборки.
SDK v7.0A - это SDK, установленный вместе с Visual Studio 2010 (A указывает, что это версия VS). С тех пор была выпущена более новая версия. Microsoft Windows SDK для Windows 7 и.NET Framework AKA v7.1.
Я установил это на моем сервере сборки. А затем с помощью командной строки Windows SDK 7.1 (Пуск => Все программы => Microsoft Windows SDK 7.1) я установил версию SDK по умолчанию равной 7.1.
шаги:
cd Setup
WindowsSdkVer.exe -version:v7.1
Изменить, чтобы включить комментарий LordHits: не нужно устанавливать весь SDK. Достаточно установить только параметры ".NET Development/Intellisense и справочные сборки" и ".NET Development/Tools".
Просто передайте параметр GenerateSerializationAssemblies со значением Off в MsBuild.
msbuild.exe /p:GenerateSerializationAssemblies=Off
Я вручную передаю переменные в MSBuild на сервере сборки.
msbuild.exe MyProject.csproj "/p:TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools" "/p:AspnetMergePath=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools"
Я недавно столкнулся с подобной проблемой на нашем сервере сборки.
Я скопировал папку 7.0A (C:\Program Files\Microsoft SDKs\Windows\7.0A) со своего компьютера (на котором установлена VS2010) на сервер сборки в том же месте.
После этого создайте следующий раздел реестра: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A. Установите InstallationFolder в C:\Program Files\Microsoft SDKs\Windows\7.0A.
Вы также можете ссылаться на реестр на вашем компьютере с уже установленным VS2010, если вы не уверены, что делать с реестром на сервере сборки.
Я столкнулся с той же ошибкой, но в другой ситуации: используя VS 2010 Express и пытаясь использовать ответ Simmo для явной установки версии SDK - однако WindowsSdkVer.exe (средство установки версий), похоже, не предназначается для Express (понятно, так как он ограничен).
Я использую VS 2010 Express на Win 7 Prof. и он всегда хочет использовать v7.0A Win SDK (который не имеет всех необходимых exes), и не имеет значения, какую версию я явно установил как текущую, используя WindowsSdkVer.exe (он продолжает сообщать, что устанавливает текущую версию SDK, но для VS 2008, хотя у меня установлен только 2010 Ex.)
Поэтому мой дешевый обходной путь заключался в установке WINK SDK v7.0 (или другой версии, например v7.1), а затем переименовании папки его файловой системы в v7.0A - в основном я просто соврал VS 2010 Express, но теперь он работает!
Один из ваших проектов использует sgen.exe (Генератор сервера) для создания веб-службы. вам нужно установить SDK на Build Server или удалить ссылки на веб-сервисы из проекта.
У меня была такая же проблема на новой машине с Windows 10. Моя настройка:
- Windows 10
- Visual Studio 2015 установлен
- Windows 10 SDK
Но я не смог собрать.NET 4.0 проекты:
Die Aufgabe konnte "AL.exe" mit dem SdkToolsPath-Wert "" oder dem Registrierungsschlüssel "HKEY_LOCAL_MACHINE \ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ \Microsoft\Microsoft SDK \Windows\v8.0A\WinSDK-NetFx40Tools-x86
Решение: После попытки (и неуспешного) установить Windows 7 SDK (поскольку он также включает в себя.NET 4.0 SDK) мне нужно было установить Windows 8 SDK и убедиться, что ".NET Framework 4.5 SDK" установлен.
Это безумие... но сработало.
Я подозреваю, что файл целей переопределяет путь к инструментам, я быстро просмотрел этот файл и установил для SDKToolsPath значение $TargetFrameworkSDKToolsDirectory в соответствии с некоторыми из целей в нем. Я не думаю, что вам все равно нужно устанавливать их в среде, но они могут нуждаться в исправлении в файлах вашего проекта.
Обратите внимание, что согласно этой странице http://nant.sourceforge.net/ Nant не поддерживает.Net 4.0, может ли это быть реальной проблемой?
Извините, я знаю, что это на самом деле не отвечает на ваш вопрос:(
На самом деле у вас не установлена SDK версии 7.0A? Это проблема, которую вам нужно решить. Посмотрите в файлах установки VS2010, чтобы увидеть, что пошло не так. SDK должен присутствовать в каталоге c:\program files\microsoft sdks\windows\7.0a, и указанный раздел реестра также должен присутствовать. Работа с версией 6.0a sgen.exe не годится, она должна использовать неправильный компилятор.
Задавать Sdk40ToolsPath скорее, чем SdkToolsPath указать местоположение, отличное от каталога установки.
Я столкнулся с аналогичной проблемой с AL.exe, потому что я просто скопировал инструменты на сборочную машину, а не установил SDK, поэтому обычные ключи реестра отсутствовали. Я запустил сборку с диагностическим выводом (/verbosity: диагностика) и заметил, что было определено несколько путей инструментов SDK: Sdk40ToolsPath, Sdk35ToolsPath и SdkToolsPath. Установка Sdk40ToolsPath для указания на папку bin соответствующей версии SDK решила проблему для меня.
У нас есть ПК для сборки winXP, и мы используем Visual Build Pro 6 для сборки нашего программного обеспечения. так как некоторые из наших разработчиков используют VS 2010, файлы проекта теперь содержат ссылку на "инструментальную версию 4.0", и, насколько я могу судить, это говорит Visual Build, что где-то нужно найти sdk7.x, даже если мы собираем только для.NET 3.5, Это заставило его не найти lc.exe. Я попытался обмануть его, указав все макросы на 6.0A SDK, который поставляется с VS2008, который установлен на ПК, но это не сработало.
В конце концов я получил его, загрузив и установив SDK 7.1. Затем я создал раздел реестра для 7.0A и указал путь установки на путь установки 7.1 SDK. теперь он с радостью находит совместимый "lc.exe", и весь код прекрасно компилируется. У меня есть ощущение, что теперь я также смогу скомпилировать код.NET 4.0, даже если VS2010 не установлен, но я еще не пробовал.
Сначала убедитесь, что вы уже загрузили dotNetFx40_Full_x86_x64.exe и установили (обычно это связано с Visual Stdio).
Затем быстро установите новые переменные среды в системные переменные. как ниже:
"TargetFrameworkSDKToolsDirectory":"C:\Program Files (x86)\Microsoft SDKs\Windows\vxx.0A\bin\NETFX 4.6.1 Tools"
//note:the path:'\vxx.0A\' is a variable indicating your version. it's '\v10.0A\' for me.
ToolsVersion="4.0" делает это для меня в моем проекте MSBuild:
<Project DefaultTargets="Do" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
Я исправил это, передав это как параметр командной строки в msbuild.exe:
Ваш пробег будет зависеть от версии SDK, установленной в вашей системе.
/p:TargetFrameworkSDKToolsDirectory="C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools
Я согласен с ответом IanS. Не нужно устанавливать новый SDK. Просто убедитесь, что значения разделов реестра SDK35ToolsPath и SDK40ToolPath для MSBuild указывают на правильные значения разделов реестра.
В моем случае мой проект был ориентирован на.NET 3.5, и мне пришлось установить SDK35ToolsPath для ключа HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0 до $(реестр:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0A\WinSDKNetFxTools@InstallationFolder). И все заработало.
Попробуйте использовать Visual Studio "ремонт". Это сработало для меня.
Краткий ответ: в файле.csproj есть способ указать путь к sgen.exe, используя SGenToolPath:
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="14.0">
<PropertyGroup>
<SGenToolPath>C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools</SGenToolPath>
</PropertyGroup>
Ваш путь может быть другим, но SGenToolPath - то, что вы хотите.
Список других общих свойств проекта MSBuild см. По адресу: https://msdn.microsoft.com/en-us/library/bb629394.aspx
В итоге мы использовали этот параметр SGenToolPath в файле.csproj вместо того, чтобы редактировать значения реестра на сервере сборки. Редактирование значений реестра на моем локальном компьютере также работало, но было немного сложнее, и мы не хотели связываться с реестром на сервере сборки.
Для реестра: в этом случае проблема заключалась в том, что SDK40ToolsPath(s) в HKLM\SOFTWARE\Wow6432Node\Microsoft\MSBuild указывали на значение реестра $(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x86@InstallationFolder), которого не было. Я просто заменил это фактическим путем непосредственно.
Я тоже столкнулся с этой проблемой, когда пытался создать плагин с помощью Visual Studio 2017 на моем ужасно испорченном рабочем компьютере. Если вы выполните поиск в Интернете по запросу "не удается найти resgen.exe", вы можете найти все эти советы вроде "просто используйте regedit для редактирования реестра Windows, создайте здесь новый ключ и скопируйте и вставьте содержимое этой папки в эта другая папка, бла-бла-бла.'
Я потратил несколько недель, просто испортил свой реестр Windows с помощью regedit, вероятно, добавил дюжину подключей и скопировал ResGen.exe во множество разных каталогов, иногда помещая его в папку `` bin '', иногда просто сохраняя его в основной папке, и т.п.
В конце концов я понял: "Эй, если бы Visual Studio выдала более подробное сообщение об ошибке, все это не было бы проблемой". Итак, чтобы получить более подробную информацию об ошибке, я запустил MSBuild.exe непосредственно в моем файле *.csproj из командной строки:
"C:/Windows/Microsoft.NET/Framework/v4.0.3.0319/MSBuild.exe C:/Users/Todd/Plugin.csproj -fl -flp:logfile="C:/Users/Todd/Desktop/error_log.log";verbosity=diagnostic"
Конечно, вам придется изменить данные пути в соответствии с вашей ситуацией, но обязательно укажите 1) полный путь к MSBuild.exe 2) полный путь к вашему файлу *.csproj 3) -fl -flp:logfile= part, который сообщит MSBuild о необходимости создания файла журнала для каждого шага, предпринятого в процессе, 4) местоположение, в котором вы хотите сохранить файл *.log и 5);verbosity= диагностический, который в основном просто сообщает MSBuild для включения ТОННЫ подробностей в файл *.log.
После этого сборка, как всегда, завершится ошибкой, но у вас останется файл *.log, показывающий , где именно MSBuild искал ваш файл ResGen.exe. В моем случае в нижней части файла *.log я обнаружил:
Compiling plug-in resources (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6.2\WinSDK-NetFx40Tools-x86 (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6.1\WinSDK-NetFx40Tools-x86 (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6\WinSDK-NetFx40Tools-x86 (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\Windows\v8.1a\WinSDK-NetFx40Tools-x86 (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\Windows\v8.0a\WinSDK-NetFx40Tools-x86 (Task ID:41)
MSBUILD: error : Failed to locate ResGen.exe and unable to compile plug-in resource file "C:/Users/Todd/PluginResources.resx"
Таким образом, MSBuild искал ResGen.exe в пяти отдельных каталогах, а затем отказался. Это та информация, которую вы просто не можете получить из сообщения об ошибке Visual Studio, и она решает проблему: просто используйте regedit, чтобы создать ключ для любого из этих пяти местоположений, и поместите значение "InstallationFolder" в ключ, который должен указывать на папку, в которой находится ваш ResGen.exe (в моем случае это была "C:\Program Files\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools").
Если вы специализируетесь в гуманитарных науках, как и я, без опыта работы в компьютерах, у вас может возникнуть соблазн просто отредактировать чертову реестр Windows и скопировать ResGen.exe повсюду, когда вы столкнетесь с такой ошибкой (которая конечно, плохая практика). Лучше следовать процедуре, описанной выше: 1) Запустите MSBuild.exe непосредственно в вашем файле *.csproj, чтобы узнать точное место, где MSBuild ищет ResGen.exe, затем 2) точно отредактируйте реестр Windows, чтобы MSBuild мог найти ResGen. исполняемый.
У меня была похожая проблема, особенно сбой msbuild: MSB3086, MSB3091: "AL.exe", "resgen.exe" не найден
На 64-битной машине с Windows 7 я установил.Net framework 4.5.1 и Windows SDK для Windows 8.1.
Хотя в настройках SDK говорилось, что он обновлен, вероятно, это не так. Я решил проблему, удалив все установленные версии SDK, а затем установил следующее в следующем порядке:
http://www.microsoft.com/en-us/download/details.aspx?id=3138
http://www.microsoft.com/en-us/download/details.aspx?id=8279
http://msdn.microsoft.com/en-us/windows/desktop/hh852363.aspx
http://msdn.microsoft.com/en-us/windows/desktop/aa904949.aspx
У меня была та же проблема, и я установил Windows SDK 7.0 и Windows SDK 7.1, которые не устранили проблему. Причиной проблемы для меня было то, что библиотека классов, создающих проблемы, была построена с помощью Target Framework.NET Framework 2.0.
Я изменил его на.NET Framework 4.0 и работал локально, и при проверке на сервере сборки он был успешно собран.
У меня была похожая проблема. Я сделал проект, используя Visual Studio 2010 а затем получил вышеуказанную ошибку, когда я скомпилировал его с помощью Visual Studio 2012, Я просто скопировал все содержимое C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A в C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A и это решило мою проблему.
У меня только что была эта ошибка с файлом.sln, который был изначально создан в Visual Studio 2010 (и создавался в Visual Studio 2010 и TFS 2010). Я изменил файл решения, чтобы НЕ создавать проект, который не должен был быть построен в конкретной конфигурации, и Visual Studio изменила заголовок файла решения с:
Microsoft Visual Studio Solution File, Format Version 11.00
# Visual Studio 2010
Для того, чтобы:
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 14
VisualStudioVersion = 14.0.24720.0
MinimumVisualStudioVersion = 10.0.40219.1
Возврат к исходной версии 2010 года решил мою проблему. Я думаю, что обратная совместимость в Visual Studio до сих пор не усовершенствована.
Помимо модов реестра, вам может потребоваться изменить версию.net SDK, для которой установлены ваши настройки в Visual Studio.
У меня возникла эта проблема, и я решил проверить настройки отладки проекта.
Project => Свойства панели инструментов => Кнопка "Параметры отладки при предварительной компиляции"
Target Framework (все конфигурации) был установлен на 3.0, которого нет в моей системе.
Я изменил это на 4.0, затем пришлось перезапустить проект и Visual Studio 2010.
Затем проект собран без ошибок и запущен.
CMD обертка
Я перепробовал все вещи отсюда и даже больше. Ничто не помогло мне.
Я применил обертки CMD для MSBuild и DevEnv.com.
Основная идея такой оболочки - создать подготовленную среду, вызывая командные строки из поставки Visual Studio. А затем передать стандартные входные параметры на вызов MSBuild или DevEnv.com.
Во всяком случае, на моем сборочном сервере теперь я могу создавать проекты из разных версий Visual Studio.
Как пользоваться
Мне пришлось заменить вызовы MSBuild и DevEnv вызовом оболочек моего пакетного файла.
И я не изменил никаких входных параметров. В качестве примера для моего вызова оболочки MSBuild:
MsBuild_Wrapper.bat MySolution.sln /target Build /property:Configuration=Release
Готовое решение
На самом деле, у меня было гораздо больше проблем с переходом с VS 2010 на VS 2015. Но этот был первым и самым сложным.
Итак, мой скромный рецепт спасения для Build Server здесь. Возможно, с первого момента там трудно понять весь этот стиль CMD, но я надеюсь, что любая логика очевидна.
Советы
ЕстьMSBuild Command Prompt for Visual Studio а также Developer Command Prompt for Visual Studio
Я использую их соответствующим образом для MSBuild и DevEnv.com. Но, вероятно, командной строки MSBuild будет достаточно.
Для VS 2015 эти командные строки здесь C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\, Или посмотрите меню программ Windows.
Чтобы передать все входные параметры в MSBuild или DevEnv внутри командного файла, я использовал CALL MSBuild %*