Запуск MSBuild не удается прочитать SDKToolsPath

Я не мог поставить 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 и ссылки на сборки" и ".Net разработки/инструменты" вариантов достаточно.

просто передайте параметр GenerateSerializationAssemblies со значением Off в MsBuild.

msbuild.exe /p:GenerateSerializationAssemblies=Off

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

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

после создать следующий раздел реестра: HKEY_LOCAL_MACHINE\программное обеспечение\Майкрософт\Microsoft пакет SDK папке\Windows\В7.0А. Установите InstallationFolder в C:\Program файлы\Microsoft SDKs\Windows\7.0 A.

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

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

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

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

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

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

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

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

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

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

Set Sdk40ToolsPath, а не SdkToolsPath указать расположение каталога установки.

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

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

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

но я не мог построить проекты .NET 4.0:

Die Aufgabe konnte " AL.ехе" МИТ дем SdkToolsPath-Верт "" Одер дем Registrierungsschlüssel "раздел HKEY_LOCAL_MACHINE\программное обеспечение\Майкрософт\Майкрософт SDKs\Windows\v8. 0A\WinSDK-NetFx40Tools-x86

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

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

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

У нас относится к сборки ПК, и использовать визуальный строят про 6, чтобы построить нашу программу. поскольку некоторые из наших разработчиков используют VS 2010, файлы проекта теперь содержат ссылку на" tool version 4.0", и из того, что я могу сказать, это говорит о том, что Visual Build должен найти sdk7.x где-то, хотя мы строим только для .NET 3.5. Это заставило его не найти lc.исполняемый. Я попытался обмануть его, указав все макросы на 6.0 a sdk, который поставляется с VS2008, который установлен на ПК, но этого не произошло работа.

Я в конечном итоге получил его работу, загрузив и установив sdk 7.1. Затем я создал раздел реестра для 7.0 A и указал путь установки на путь установки 7.1 sdk. теперь он с радостью находит совместимый " lc.exe " и весь код компилируется нормально. У меня есть ощущение, что теперь я также смогу скомпилировать код .NET 4.0, даже если VS2010 не установлен, но я еще не пробовал.

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

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

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

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

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

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

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

помимо модов реестра, вам может потребоваться изменить версию .NET sdk, заданную в настройках Visual Studio.

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

Проект = > Свойства Панели Инструментов = > Отладка Заранее параметры компиляции кнопку

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

Я изменил это на 4.0, затем пришлось перезапустить проект и Визуальная Студия 2010.

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

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

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

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 до сих пор не была усовершенствована.

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

CMD wrapper
Я пробовал все вещи отсюда и даже больше. Мне ничего не помогало.

я применил оболочки CMD для MSBuild и DevEnv.com.
Основная идея внутри такой оболочки заключается в создании подготовленной среды путем вызова командных подсказок из Visual Studio supply. А затем передать стандартные входные параметры в вызов MSBuild или DevEnv.com.

в любом случае, на моем build-сервере теперь я могу создавать проекты из разных визуальных Студийная версия.

как использовать
Мне пришлось заменить вызовы 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 %*