При запуске MSBuild не удается прочитать SDKToolsPath - PullRequest
126 голосов
/ 28 апреля 2010

Привет, у меня возникла небольшая проблема с запуском сценария NAnt, который использовался для правильной сборки моего веб-сайта на основе .Net 2.0 при компиляции с VS2008 и связанными с ним инструментами. Я недавно обновил все файлы проекта / решения до VS2010, и теперь моя сборка завершается с ошибкой:

[ВЫПЛН] 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, но я не сталкивался с конкретной версией .Net 4.0. Windows SDK.

После небольшого количества экспериментов и исследований я, наконец, просто установил новую переменную окружения "SDKToolsPath" и указал ее на копию sgen.exe в моей папке Windows 6.0 SDK. Это вызвало ту же ошибку, но заставило меня заметить, что, хотя переменная окружения SDKToolsPath установлена ​​(подтверждено, что я могу «отобразить» ее в командной строке, и она имеет ожидаемое значение), сообщение об ошибке, похоже, указывает не читается (обратите внимание на пустые кавычки).

Большая часть информации, которую я нашел, относится к .Net 3.5 (или более ранней версии). Не много 4.0 связано там еще. Поиск кода ошибки MSB3086 также не принес ничего полезного. Есть идеи, что это может быть?

Scott

Ответы [ 24 ]

3 голосов
/ 01 июля 2010

Установите Sdk40ToolsPath вместо SdkToolsPath, чтобы указать расположение, отличное от каталога установки.

Я столкнулся с аналогичной проблемой с AL.exe, потому что я просто скопировал инструменты на сборочную машину, а не установил SDK, поэтому обычные ключи реестра отсутствовали. Я запустил сборку с диагностическим выводом (/ verbosity: диагностика) и заметил, что определены несколько путей инструментов SDK: Sdk40ToolsPath, Sdk35ToolsPath и SdkToolsPath. Установка Sdk40ToolsPath для указания на папку bin соответствующей версии SDK решила проблему для меня.

2 голосов
/ 05 апреля 2012

У нас есть ПК для сборки 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 не установлен, но я еще не пробовал.

2 голосов
/ 16 декабря 2010

Я согласен с ответом 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). И все заработало.

2 голосов
/ 26 февраля 2013

ToolsVersion = "4.0" делает это для меня в моем проекте MSBuild:

<Project DefaultTargets="Do" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
1 голос
/ 18 мая 2016

Краткий ответ: в файле .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), которого не было. Я просто заменил это фактическим путем непосредственно.

1 голос
/ 27 февраля 2018

Сначала убедитесь, что вы уже загрузили 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.

1 голос
/ 22 января 2013

У меня была та же проблема, и я установил Windows SDK 7.0 и Windows SDK 7.1, которые не устранили проблему.Причиной проблемы для меня было то, что библиотека классов, создающих проблемы, была построена с помощью Target Framework .NET Framework 2.0.

Я изменил его на .NET Framework 4.0 и работал локально, а при проверке на сервере сборки собрал его успешно.

1 голос
/ 30 сентября 2014

У меня была похожая проблема, особенно msbuild fails: 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

0 голосов
/ 18 июня 2019

Я тоже столкнулся с этой проблемой, пытаясь создать плагин с помощью 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. ехе.

0 голосов
/ 20 января 2012

Помимо модов реестра, вам может потребоваться изменить версию .net sdk, для которой установлены ваши настройки в Visual Studio.

У меня возникла эта проблема, и я решил проверить настройки отладки проекта.

Project => Свойства панели инструментов => Отладка Кнопка параметров расширенной компиляции

Целевая платформа (все конфигурации) было установлено значение 3.0, которого нет в моей системе.

Я изменил это на 4.0, затем пришлось перезапустить проект и Visual Studio 2010.

Затем проект был собран без ошибок и запущен.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...