Запуск 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, і встановлено пакет SDK Microsoft Windows.

Тепер у мене є попередні версії (.Net 3.5) Windows SDK, встановлені на сервері збірки, і встановлено повний .Net 4.0 фреймворк, але я не перебігав.

Після трохи експериментів та досліджень я нарешті просто встановив нову змінну середовища "SDKToolsPath" і вказав на копію sgen.exe в папці sdk Windows 6.0. Це призвело до тієї ж помилки, але я змусив помітити, що навіть незважаючи на те, що ISKT-змінну SDKToolsPath встановлено (підтвердив, що я можу "повторити" її в командному рядку, і вона має очікуване значення), повідомлення про помилку, схоже, вказує, що це не читається (зверніть увагу на порожні цитати).

Більшість інформації, яку я знайшов, є специфічною .Net 3.5 (або раніше). Не так багато 4,0 пов'язаних там ще. Пошук коду помилки MSB3086 також не спричинив нічого корисного. Будь-яка ідея, що це може бути?

Скотт


Пов’язаний випуск у цій публікації. Я також розмістив відповідь там. stackoverflow.com/questions/1109955/…
Дієго С.

Відповіді:


15

Мені довелося кусати кулю і встановити VS 2010 на наш сервер збирання, щоб виправити цю проблему. Наскільки я бачу, в MSDN ніде не доступна версія версії SDK Windows 7.0A. Однак, здається, що встановити VS 2010, щоб встановити його, створивши 7.0A реєк і папку 7.0A у файлах програми \ Microsoft SDKs \ Windows.


9
Я вважаю за краще не встановлювати Visual Studio 2010 на сервер. Я вважаю за краще пропозицію Сіммо нижче встановити для поточної версії SDK для Windows v7.1. WindowsSdkVer.exe знаходиться в C: \ Program Files \ Microsoft SDKs \ Windows \ v7.1 \ Setup (припустимо, що він встановлений на C: \ Program Files).
Філіп

55
Я виявив, що якщо встановити лише Windows SDK 7.1 та .NET 4.0. MSBuild не встановлює належних шляхів до SDK40ToolsPath та SDK35ToolsPath. Щоб виправити це, мені довелося змінити кілька записів у HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0: "SDK40ToolsPath" = "$ (Реєстр: HKEY_LOCAL_MACHINE \\ SOFTWARE \\ Microsoft \\ Microsoft SDKs \\ Windows \\ v7 .1 \\ WinSDK-NetFx40Tools-x86 @ InstallationFolder) "Аналогічно змініть" v7.0A "на" v7.1 "в SDK35ToolsPath та FrameworkSDKRoot.
BlueMonkMN

7
Шиш - я знову зіткнувся з тією ж проблемою, поглянув на це і знайшов власну відповідь! :) Щось, здається, змінило мою зміну, і я думаю, що мені доведеться знову застосувати її вручну.
BlueMonkMN

3
ПРИСТРІЙ! Останні патчі .NET 4.0 (2011-08-11) замінили ці параметри реєстру!
si618

8
Оновлення моєї попередньої відповіді. Здається, що на 64-бітних ОС може знадобитися також оновлення подібних значень у HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild \ ToolsVersions \ 4.0, а може знадобитися встановлення 8.0 SDK або оновлення значень у HKEY_LOCAL_MACHINE \ ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 \ 11.0 та HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 \ 11.0 Я зробив усе вищезазначене, за винятком встановлення 8.0 SDK, і не зміг зібрати до моменту, як я (як одна партія) крок) включив мої оновлення до всіх вузлів 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 and Reference Assembly" та ".NET Development / Tools".


4
Це прекрасно працювало для мене в поєднанні з копіюванням файлів на C: \ Program Files \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications з моєї машини VS.
dnolan

1
Я зіткнувся з тією ж проблемою, що і оригінальний автор, і ця відповідь вирішила її! Мені не довелося встановлювати Visual Studio 2010 на свою машину Build.
РішенняYogi

37
Крім того, для уточнення не потрібно встановлювати весь SDK. Досить встановити лише параметри ".NET Development / Intellisense and Reference Assembly" та ".NET Development / Tools". Це та копіювання файлів із коментаря dnolan.
LordHits

Дякую за це рішення, воно прекрасно працювало для мене на нашому сервері збирання! FYI - для всіх, хто може запитати, сервер збирання - це Windows Server 2008 x64.
Адам Вебер

Дуже дякую за цю відповідь; зіткнувся з тим же питанням і при роботі з цим.
Абе

20

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

msbuild.exe /p:GenerateSerializationAssemblies=Off

7
msbuild.exe / p: GenerateSerializationAssemblies = Вимкнено
Даніель

2
Або встановіть "Створити збірку серіалізації: Вимкнено" на вкладці "Створення" властивостей проекту веб-служби.
самнерік

6
Що це робить саме?
розчавити

1
GOTCHA: Якщо ви вимкнете його на вкладці збірки, переконайтеся, що ви робите це для відповідної конфігурації збірки (DropDown у верхній частині вкладки Build), у моєму випадку це був лише сервер збірки з проблемою, тому мені довелося змінити це в конфігурації "Випуск".
Містер

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"

1
Це те, що я закінчив робити для Windows 10 SDK на сервері без Visual Studio і Build Tools 2019. Жодне з інших рішень, здавалося, не допомогло, і це зробило трюк чисто.
Nicolás Fantone

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, якщо вас плутають, що робити з реєстром на сервері збірки.


Для мене відповідь Сіммо не спрацювала - хоч цей злом реєстру зробив (Win 2K3 SP2).
FinnNk

7

Я зіткнувся з тією ж помилкою, але в іншій ситуації: використовуючи VS 2010 Express і намагаючись використовувати відповідь Сіммо, щоб явно встановити версію SDK - однак WindowsSdkVer.exe (інструмент встановлення версій), схоже, не націлений на Express (зрозуміло, оскільки обмежений ).

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

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


5

Один з ваших проектів використовує sgen.exe (Генератор сервера) для створення веб-сервісу. вам потрібно встановити SDK, щоб створити сервер або видалити посилання веб-служб з проекту.


1
Або встановіть "Створити збірку серіалізації: Вимкнено" на вкладці "Створення" властивостей проекту веб-служби.
самнерік

1
GOTCHA: Якщо ви вимкнете його на вкладці збірки, переконайтеся, що ви робите це для відповідної конфігурації збірки (DropDown у верхній частині вкладки Build), у моєму випадку це був лише сервер збірки з проблемою, тому мені довелося змінити це в конфігурації "Випуск".
Містер

4

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

Зауважте, що згідно з цією сторінкою http://nant.sourceforge.net/ Nant не підтримує .Net 4.0, це може бути справжньою проблемою?

Вибачте, я знаю, що це насправді не відповідає на ваше запитання :(


Правильно, NAnt ще не підтримує формати файлів проекту / рішення для VS2010, тому я закликаю MSBuild для фактичного кроку компіляції. Перевірте файл цілей.
Скотт Мейфілд

4

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

  • Windows 10
  • Встановлено Visual Studio 2015
  • SDK для Windows 10

Але я не зміг створити проекти .NET 4.0:

Die Aufgabe konnte "AL.exe" mit dem SdkToolsPath-Wert "" oder dem Registrierungsschlüssel "HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v8.0A \ WinSDK-NetFx40Tools-x86

Рішення: Після спроби (і відмови) встановити Windows 7 SDK (тому що також включає.

Це божевільно ... але працювало.


Це саме допомогло мені і в Windows 10.
Бурберт

3

У вас фактично не встановлена ​​версія SDK версії 7.0A? Це проблема, яку вам потрібно буде виправити. Подивіться у файли журналів установки VS2010, щоб побачити, що пішло не так. SDK повинен бути присутнім у c: \ програмних файлах \ microsoft sdks \ windows \ 7.0a, а також перелічений ключ реєстру також повинен бути присутнім. Запуск з версією 6.0a sgen.exe не в порядку, він повинен використовувати неправильний компілятор.


1
Пам'ятайте, що це сервер збірки, тому встановлення повного середовища VS2010 не було моїм першим вибором. Мені не вдалося знайти доступне завантаження Windows SDK 7.0a
Скотт Мейфілд

3
Я не бачу проблеми. Виконання збірки на машині, конфігурація якої не відповідає розробникам, це проблема, яка швидко зносить вас.
Ганс Пасант

3

Встановіть, Sdk40ToolsPathа не SdkToolsPathвказуйте розташування, відмінне від каталогу встановлення.

Я потрапив у аналогічну проблему з AL.exe, тому що я просто копіював інструменти на машину збирання, а не встановлював SDK, тому звичайні ключі реєстру відсутні. Я запустив збірку з діагностичним виведенням (/ багатослівність: діагностика) і помітив, що визначено кілька шляхів інструментів SDK: Sdk40ToolsPath, Sdk35ToolsPath та SdkToolsPath. Встановлення Sdk40ToolsPath для вказівки на відповідну папку бін версії SDK вирішило проблему для мене.


Де ви встановили Sdk40ToolsPath?
Майкл Фрейджім

Я б припустив, що його потрібно додати до шляху довкілля. Однак це не спрацювало для мене.
Тімоті Лі Рассел

Вибачте, це було так давно, що я забув деталі, але, думаю, це була змінна середовище або встановлена ​​у файлі проекту MSBuild. Також зауважте, що початкове запитання стосується .NET Framework 4.0 / VS2010, але для пізніших версій фреймворку можуть знадобитися різні змінні.
IanS

2

Я згоден з відповіддю IanS. Не потрібно встановлювати новий SDK. Просто переконайтесь, що значення ключів реєстру SDK35ToolsPath та SDK40ToolPath for 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

У нас є ПК для складання 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

ToolsVersion = "4.0" робить це для мене в моєму проекті MSBuild:

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

Ну, в моєму випадку я використовував 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.


Це вирішує проблему. Лише підказка, якщо хтось має таку саму проблему, як я. Перемінну Env потрібно називати TargetFrameworkSDKToolsDirectory, а не SdkToolsPath !!!
Маркус

1

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

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


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


1

Я теж зіткнувся з цією проблемою, намагаючись створити плагін за допомогою Visual Studio 2017 на моєму жахливо заплутаному комп’ютері на робочому місці. Якщо ви шукаєте в Інтернеті "не в змозі знайти resgen.exe", ви можете знайти всі ці поради, такі як " просто скористайтеся regedit, щоб відредагувати свій реєстр Windows і зробити тут новий ключ і скопіювати та вставити вміст цієї папки в ця інша папка, бла-бла-бла. '

Я витратив тижні, просто псуючи свій реєстр Windows з regedit, ймовірно, додав десяток під-ключів і скопіював ResGen.exe в безліч різних каталогів, іноді поміщаючи їх у папку «бін», іноді просто зберігаючи її в головній папці, тощо.

Врешті-решт я зрозумів: "Ей, якби 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 = частина, яка скаже MSBuild створити файл журналу кожного кроку, який він пройшов у процесі; 4) місце, де ви хочете зберегти файл * .log, і 5); verbosity = діагностика, яка в основному просто повідомляє MSBuild включити TONS деталей у файл * .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 Інструменти").

Якщо ви такий гуманітарний гуманітарний діяч, як я, що не має досвіду роботи на комп’ютерах, можливо, вам сподобається просто відредагувати його з реєстру Windows та скопіювати вставити ResGen.exe в усьому місці, зіткнувшись із такою помилкою (яка є звичайно, погана практика). Краще дотримуватися описаної вище процедури: 1) Запустіть MSBuild.exe безпосередньо у вашому файлі * .csproj, щоб з’ясувати точне місце, де MSBuild шукає ResGen.exe, а потім 2) відредагуйте реєстр Windows саме так, щоб MSBuild міг знайти ResGen. exe


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

Схоже, я використовую MSBuild версії 4.0.30319. У мене також встановлені версії 3.5, 3.0 та 2.0.50727 на цьому комп’ютері. Я спробував запустити ці версії MSBuild у моєму файлі * .csproj (таким же чином, як описано вище), але це не вийшло ... навіть не створив файл * .log. /// Коли ви запускаєте MSBuild у вашому файлі * .csproj, чи принаймні комп'ютер створює файл журналу *? Я розумію, що є файл журналу, просто немає конкретної інформації щодо шляхів, які шукали під час пошуку ResGen.exe - це правильно?
todbott

Схоже, у мене є та сама версія MSBuild (4.0.30319). І так, ви праві. Я отримую файл журналу, але він не дає ніякої інформації про шляхи до реєстру. Який із п'яти шляхів, які ви розмістили вище, ви в кінцевому підсумку використовували?
користувач11809641

Я використовував 1-й шлях у списку - щойно додав "InstallationFolder" в ключ SOFTWARE \ WOW6432Node \ Microsoft \ Microsoft SDKs \ NETFXSDK \ 4.6.2 \ WinSDK-NetFx40Tools-x86. Також файл * .log насправді надзвичайно довгий - у моєму випадку тисячі рядків. Я не міг знайти інформацію про шлях неозброєним оком. Я в кінцевому підсумку відкрив файл * .log у Блокноті та шукав "ResGen.exe", який привернув увагу моєї відповідної області (інформації про шляхи).
todbott

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

1

Я виправив це, передавши цей параметр командного рядка в msbuild.exe:

Пробіг варіюватиметься залежно від версії SDK у вашій системі

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

0

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

У мене була ця проблема і вирішив перевірити налаштування налагодження проекту.

Project => Властивості панелі інструментів => Кнопка «Налаштування попереднього компіляції»

Цільова рамка (усі конфігурації) була встановлена ​​на 3,0, що не в моїй системі.

Я змінив це на 4.0, потім довелося перезапустити проект і Visual Studio 2010.

Потім проект будувався без помилок і запускався.


Я допустив помилку, це знайдіть у наступному. Проект => Властивості панелі інструментів => Кнопка компілювати заздалегідь параметри компіляції Я також створив новий проект, а для нового проекту .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 %*

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.