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

130

Привет, у меня возникла небольшая проблема с запуском сценария 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 в моей папке sdk Windows 6.0. Это сгенерировало ту же ошибку, но заставило меня заметить, что, хотя переменная среды SDKToolsPath установлена (подтверждено, что я могу "повторить" ее в командной строке и она имеет ожидаемое значение), сообщение об ошибке, похоже, указывает, что это не читается (обратите внимание на пустые кавычки).

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

Скотт

.net msbuild Скотт Мэйфилд
источник

Связанная проблема в этом сообщении. Я тоже отправил туда ответ. stackoverflow.com/questions/1109955/…

Диего К.

15

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

Джон Ханн
источник

9

Я предпочитаю не устанавливать Visual Studio 2010 на сервере. Я предпочитаю приведенное ниже предложение Simmo по установке текущего Windows SDK на v7.1. WindowsSdkVer.exe находится в C: \ Program Files \ Microsoft SDKs \ Windows \ v7.1 \ Setup (при условии, что он был установлен в C: \ Program Files).

Philippe

55

Я обнаружил, что если вы устанавливаете только Windows SDK 7.1 и .NET 4.0. MSBuild не устанавливает правильные пути к SDK40ToolsPath и SDK35ToolsPath. Чтобы исправить это, мне пришлось изменить несколько записей в 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) «Аналогичным образом измените« v7.0A »на« v7.1 »в SDK35ToolsPath и FrameworkSDKRoot.

BlueMonkMN

7

Черт возьми, я сам снова столкнулся с той же проблемой, искал ее и нашел свой собственный ответ! :) Что-то вроде сбросило мои изменения, и я думаю, мне придется вручную применить их снова.

BlueMonkMN

3

ARRRGH! Последние исправления .NET 4.0 (2011-08-11) перезаписали эти параметры реестра!

si618

8

Обновите мой предыдущий ответ. Похоже, что в 64-битных ОС также может потребоваться обновить аналогичные значения в HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild \ ToolsVersions \ 4.0, и может потребоваться установить SDK 8.0 или обновить значения в HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 \ 11.0 и HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 \ 11.0 Я сделал все вышеперечисленное, за исключением установки 8.0 SDK, и не смог скомпилировать, пока я (как одна партия step) включены мои обновления для всех узлов 4.0 \ 11.0.

BlueMonkMN

227

Я не мог столкнуться с размещением 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».

Simmo
источник

4

Это отлично сработало для меня в сочетании с копированием файлов в C: \ Program Files \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications с моей машины VS.

dnolan 02

1

Я столкнулся с той же проблемой, что и первоначальный автор, и этот ответ решил ее! Мне не нужно было устанавливать Visual Studio 2010 на моем компьютере для сборки.

SolutionYogi

37

Кроме того, чтобы уточнить, не нужно устанавливать весь SDK. Достаточно установить только опции «.NET Development / Intellisense и справочные сборки» и «.NET Development / Tools». Это и копирование файлов из комментария dnolan.

LordHits

Спасибо за это решение, оно отлично сработало на нашем сервере сборки! К вашему сведению - для всех, кто может сомневаться, сервер сборки - это Windows Server 2008 x64.

Адам Вебер

Большое спасибо за этот ответ; столкнулся с той же проблемой при работе с этим.

Abe

20

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

msbuild.exe /p:GenerateSerializationAssemblies=Off

Даниил
источник

7

msbuild.exe / p: GenerateSerializationAssemblies = Off

Дэниел

2

Или установите «Создать сериализацию сборки: Выкл.» На вкладке «Сборка» в свойствах проекта веб-службы.

samneric

6

Что именно это делает?

Crush

1

GOTCHA: если вы отключите его на вкладке сборки, убедитесь, что вы сделали это для соответствующей конфигурации сборки (DropDown вверху вкладки Build), в моем случае это был просто сервер сборки с проблемой, поэтому мне пришлось измените это в конфигурации «Release».

Myster

14

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

AaronLS

14

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

Der_Meister
источник

1

Это то, что я в итоге сделал для Windows 10 SDK на сервере без Visual Studio и Build Tools 2019. Казалось, что ни одно из других решений не помогло, и это помогло чисто.

Николас

8

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

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

brandogs
источник

Для меня ответ Симмо не сработал - хотя этот взлом реестра сработал (Win 2K3 SP2).

FinnNk

7

Я столкнулся с той же ошибкой, но в другой ситуации: использую 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.)

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

Джон К
источник

5

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

Maer007
источник

1

Или установите «Создать сериализацию сборки: Выкл.» На вкладке «Сборка» в свойствах проекта веб-службы.

samneric

1

GOTCHA: если вы выключите его на вкладке сборки, убедитесь, что вы сделали это для соответствующей конфигурации сборки (DropDown вверху вкладки Build), в моем случае это был просто сервер сборки с проблемой, поэтому мне пришлось измените это в конфигурации «Release».

Myster

4

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

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

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

Стив
источник

Верно, NAnt еще не поддерживает форматы файлов проекта / решения для VS2010, поэтому я обращаюсь к MSBuild для фактического этапа компиляции. Проверим файл целей.

Скотт Мэйфилд

4

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

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

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

Получить файл «AL.exe» с использованием SdkToolsPath-Wert или «Registrierungsschlüssel» HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v8.0A \ WinSDK-NetFx40Tools-x86

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

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

Роберт Мюхсиг
источник

Это точно помогло мне и в Windows 10.

bourbert

3

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

Ганс Пассант
источник

1

Помните, что это сервер сборки, поэтому установка всей среды VS2010 не была моим первым выбором. Мне не удалось найти какой-либо доступный для загрузки Windows SDK 7.0a

Скотт Мэйфилд,

3

Я не вижу проблемы. Запуск сборки на машине, конфигурация которой не соответствует машинам разработчиков, это проблема, которая быстро утомит вас.

Ханс Пассан

3

Задайте, Sdk40ToolsPathа не SdkToolsPathуказывать расположение, отличное от каталога установки.

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

Ians
источник

Где вы ставили Sdk40ToolsPath?

Майкл Фрейджейм,

Я бы предположил, что его нужно добавить в путь к среде. Тем не менее, это не сработало для меня.

Тимоти Ли Рассел

Извините, это было так давно, я забыл подробности, но я думаю, что это была либо переменная среды, либо заданная в файле проекта MSBuild. Также обратите внимание, что исходный вопрос относится к .NET Framework 4.0 / VS2010, но для более поздних версий платформы могут потребоваться другие переменные.

IanS 07

2

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

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

Анна
источник

2

У нас есть компьютер для сборки winXP, и мы используем Visual Build Pro 6 для сборки нашего программного обеспечения. поскольку некоторые из наших разработчиков используют VS 2010, файлы проекта теперь содержат ссылку на «инструмент версии 4.0», и, насколько я могу судить, это говорит Visual Build, что нужно где-то найти sdk7.x, хотя мы собираем только для .NET 3.5 , Это привело к тому, что он не смог найти lc.exe. Я попытался обмануть его, указав все макросы на SDK 6.0A, поставляемый с VS2008, установленным на компьютере, но это не сработало.

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

Херби Марэ
источник

2

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

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

AlexeiOst
источник

Ну, в моем случае я использовал ToolsVersion = "14.0" для VS 2015, и это решило проблему

AndrewSilver

2

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

TommyWhite
источник

Это решает проблему. Просто подсказка, если у кого-то такая же проблема, как у меня. Переменная Env должна называться TargetFrameworkSDKToolsDirectory, а не SdkToolsPath !!!

Маркус

1

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

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

Роб Брэмхолл
источник

1

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

Старнуто ди топо
источник

1

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

TomEberhard
источник

1

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

todbott
источник

Я пробовал это, но по какой-то причине я не получаю список отображаемых вами путей. Я нашел на этом сайте пост, похожий на ваш: community.sdl.com/developers-more/developers/… так что я знаю, что он должен работать, но безрезультатно. Какую версию MSBuild вы используете?

user11809641 02

Похоже, я использую MSBuild версии 4.0.30319. У меня также установлены версии 3.5, 3.0 и 2.0.50727 на этом компьютере. Я попытался запустить эти версии MSBuild в своем файле * .csproj (так же, как описано выше), но это не сработало ... даже не создал файл * .log. /// Когда вы запускаете MSBuild для своего файла * .csproj, создает ли компьютер хотя бы * файл журнала? Насколько я понимаю, существует файл журнала, но нет конкретной информации о путях, которые искали при поиске ResGen.exe - это правильно?

todbott 05

Похоже, у меня такая же версия MSBuild (4.0.30319). И да, вы правы. Я получаю файл журнала, но он не дает никакой информации о путях в реестре. Какой из пяти путей, которые вы опубликовали выше, вы в конечном итоге использовали?

user11809641 05

Я использовал 1-й путь в списке - просто добавил папку «InstallationFolder» в ключ SOFTWARE \ WOW6432Node \ Microsoft \ Microsoft SDKs \ NETFXSDK \ 4.6.2 \ WinSDK-NetFx40Tools-x86. Кроме того, файл * .log на самом деле очень длинный - в моем случае тысячи строк. Я не мог найти информацию о пути невооруженным глазом. В итоге я открыл файл * .log в Блокноте и поискал «ResGen.exe», что привлекло мое внимание к соответствующей области (информации о путях).

todbott

1

Супер - поздравления! Вы стали одним из горстки людей (я полагаю, нескольких сотен), которые боролись с ошибками и загадками и действительно успешно скомпилировали плагин для Trados. Удачи в публикации вашего плагина, до встречи в магазине приложений SDL!

todbott

1

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

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

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

BraveNewMath
источник

0

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

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

Проект => Свойства панели инструментов => Кнопка «Параметры компиляции с расширенной отладкой»

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

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

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

Скотт Тови
источник

Я ошибся, он находится по следующему адресу. Project => Toolbar Properties => Compile Advance Compile Options button Я также создал новый проект, и для нового проекта .net было установлено значение 3.0. Таким образом, потребуется также изменить настройку по умолчанию. Скотт А. Тови

Скотт Тови

Я выяснил, что когда вы создаете проект, вверху окна есть выпадающий список всех фреймворков. В списке отображается все, независимо от того, установлено оно или нет. После того как вы выберете фреймворк и создадите проект из этого списка, он останется по умолчанию, пока вы не измените его на другую структуру для нового проекта. Это немного безрассудно, список должен содержать только те фреймворки, которые установлены в системе.

Скотт Тови

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и это решило мою проблему.

Лео Рамс
источник

3

Я бы хотел, чтобы было голосование за худшее решение в мире. Вот бы оно.

jonypony3

0

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

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

Майк Чил
источник

0

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

Ширли
источник

0

Обертка 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 %*

it3xl
источник

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

Ответы: