Запуск MSBuild не читается SDKToolsPath

Ответ 1

Мне пришлось укусить пулю и установить VS 2010 на нашем сервере сборки, чтобы исправить эту проблему. Насколько я вижу, нет версии SDK для Windows версии 7.0A в любом месте в MSDN. Тем не менее, установка VS 2010, похоже, устанавливает его, создавая ключ реестра 7.0A и папку 7.0A в Program Files\Microsoft SDKs\Windows.

Ответ 2

Я не мог столкнуться с 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/Intellisense и Reference Assemblies" и ".NET Development/Tools".

Ответ 3

Просто передайте параметр GenerateSerializationAssemblies со значением Off для вашего MsBuild.

msbuild.exe /p:GenerateSerializationAssemblies=Off

Ответ 4

Я вручную передаю переменные в 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"

Ответ 5

Я столкнулся с аналогичной проблемой недавно на нашем сервере сборки.

Я скопировал папку 7.0A (C:\Program Files\Microsoft SDKs\Windows\7.0A) с моего компьютера (на котором установлен VS2010) на сервер сборки в том же месте.

После создания следующего раздела реестра: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDK\Windows\v7.0A. Установите InstallationFolder в C:\Program Files\Microsoft SDK\Windows\7.0A.

Вы также можете ссылаться на реестр на вашем компьютере с уже установленным VS2010, если вы не уверены в том, что делать с реестром на сервере сборки.

Ответ 6

Я столкнулся с той же ошибкой, но в другой ситуации: используя VS 2010 Express и пытаюсь использовать Simmo answer, чтобы явно установите версию SDK, однако WindowsSdkVer.exe(средство установки уставок версии), похоже, не нацелено на Express (понятно, поскольку оно ограничено).

Я использую VS 2010 Express для Win 7 Prof., и он всегда хочет использовать v7.0A Win SDK (у которого нет всех необходимых exes), и не имеет значения, какую версию я явно задал как текущий, используя WindowsSdkVer.exe(он продолжает сообщать, что он установил текущую версию SDK, но для VS 2008, хотя хотя у меня установлен только 2010 Ex.)

Итак, моим дешевым обходным решением было установить v7.0 WIN SDK (или другую версию, например, v7.1), а затем переименовать ее папку с файловой системой в v7.0A - в основном я просто солгал VS 2010 Экспресс, но он работает сейчас!

Ответ 7

В одном из ваших проектов используется sgen.exe(Server Generator) для создания веб-сервиса. вам необходимо установить SDK для сборки сервера или удалить ссылки на веб-службу из проекта.

Ответ 8

Я подозреваю, что файл целей переопределяет путь к инструментам, я быстро просмотрел этот файл и устанавливает SDKToolsPath в $TargetFrameworkSDKToolsDirectory под некоторыми целевыми объектами. Я не думаю, что вам нужно будет устанавливать их в среде в любом случае, но им может потребоваться исправление в файлах проектов.

Обратите внимание, что согласно этой странице http://nant.sourceforge.net/ Нант не поддерживает .Net 4.0, может ли это быть реальной проблемой?

Извините, я знаю, что это не отвечает на ваш вопрос: (

Ответ 9

На самом деле у вас нет SDK версии 7.0A? Это проблема, которую вам нужно исправить. Просмотрите файлы журнала установки VS2010, чтобы узнать, что пошло не так. SDK должен присутствовать в c:\program files\microsoft sdks\windows\7.0a, а также должен присутствовать указанный в списке раздел реестра. Работа с версией 6.0a версии sgg.exe не подходит, она должна использовать неправильный компилятор.

Ответ 10

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

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

Ответ 11

У меня была такая же проблема на совершенно новой машине Windows 10. Моя настройка:

• Windows 10
• Установленная версия Visual Studio 2015
• Windows 10 SDK

Но я не мог создавать проекты .NET 4.0:

Die Aufgabe konnte "AL.exe" mit dem SdkToolsPath-Wert "или далее" Registrierungsschlüssel" HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDK\Windows\v8.0A\WinSDK-NetFx40Tools-x86

Решение: После попытки (и неудачи) установки SDK Windows 7 (так как это также включает .NET 4.0 SDK) мне нужно было установить SDK Windows 8 и убедиться, что установлен ".NET Framework 4.5 SDK".

Это безумие... но сработало.

Ответ 12

Я согласен с ответом IanS. Нет необходимости устанавливать новый SDK. Просто убедитесь, что значения ключа реестра SDK35ToolsPath и SDK40ToolPath для MSBuild указывают на правильность значений ключа реестра.

В моем случае мой проект был нацелен на .NET 3.5, и мне пришлось установить SDK35ToolsPath для ключа HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0 до $(реестр: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDK\Windows\v6.0A\WinSDKNetFxTools @InstallationFolder). И все сработало.

Ответ 13

У нас есть winXP build pc и используйте Visual Build Pro 6 для создания нашего программного обеспечения. поскольку некоторые из наших разработчиков используют VS 2010, файлы проекта теперь содержат ссылку на "tool version 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 не установлен, но я еще не пробовал.

Ответ 14

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

<Project DefaultTargets="Do" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

Ответ 15

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

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

Ответ 16

У меня была аналогичная проблема, особенно 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

Ответ 17

Короткий ответ: в файле .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 в HKLM\SOFTWARE\Wow6432Node\Microsoft\MSBuild  указывали на значение реестра $(Registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDK\Windows\v8.0A\WinSDK-NetFx40Tools-x86 @InstallationFolder), которого не было. Я просто заменил это фактическим путем напрямую.

Ответ 18

Сначала убедитесь, что вы уже загрузили 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 '\v10.0A\' for me. ниже: "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 '\v10.0A\' for me. "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 '\v10.0A\' for me.

Ответ 19

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

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

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

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

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

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

Ответ 20

У меня была аналогичная проблема. Я выполнил проект с использованием Visual Studio 2010, а затем получил указанную выше ошибку, когда я скомпилировал ее с помощью Visual Studio 2012. Я просто скопировал все содержимое C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A в C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A и решил свою проблему.

Ответ 21

У меня была эта ошибка с файлом .sln, который был первоначально создан в Visual Studio 2010 (и был создан Visual Studio 2010 и TFS 2010). Я изменил файл решения, чтобы НЕ построить проект, который не должен был быть построен в конкретной конфигурации, а визуальная студия изменила заголовок файла решения:

Microsoft Visual Studio Solution File, Format Version 11.00
# Visual Studio 2010

To:

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 все еще не была улучшена.

Ответ 22

попробуйте использовать визуальный студийный "ремонт". Это сработало для меня.

Ответ 23

Оболочка 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. Но этот был первым и самым сложным.
Итак, мой скромный рецепт спасения для сервера сборки здесь. Возможно, трудно понять весь этот стиль 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 %*

Ответ 24

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

Ответ 25

Я исправил это, передав это как параметр командной строки в msbuild.exe:

Ваш пробег зависит от версии SDK, установленной в вашей системе

/p:TargetFrameworkSDKToolsDirectory="C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools