MSBuild를 실행하면 SDKToolsPath를 읽을 수 없습니다.

MSBuild를 실행하면 SDKToolsPath를 읽을 수 없습니다.

---

Howdy, VS2008 및 관련 도구로 컴파일 할 때 .Net 2.0 기반 웹 사이트를 올바르게 빌드하는 데 사용되는 NAnt 스크립트를 실행하는 데 약간의 문제가 있습니다. 최근에 모든 프로젝트 / 솔루션 파일을 VS2010으로 업그레이드했으며 이제 다음 오류와 함께 빌드가 실패합니다.

[exec] C : \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Microsoft.Common.targets (2249,9) : 오류 MSB3086 : S dkToolsPath ""또는 레지스트리를 사용하여 "sgen.exe"를 찾을 수 없음 "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"를 설정하고 내 Windows 6.0 SDK 폴더의 sgen.exe 복사본을 가리 켰습니다. 동일한 오류가 발생했지만 SDKToolsPath 환경 변수가 설정되어 있지만 (명령 행에서 "echo"할 수 있고 예상 값이 있음을 확인했지만) 오류 메시지가 나타납니다. 읽을 수 없습니다 (빈 따옴표에 유의하십시오).

내가 찾은 대부분의 정보는 .Net 3.5 또는 이전 버전입니다. 아직 4.0과 관련이 없습니다. 오류 코드 MSB3086을 검색해도 유용한 정보가 없습니다. 이것이 무엇인지 알 수 있습니까?

스캇

---

이 문제를 해결하려면 총알을 물고 빌드 서버에 VS 2010을 설치해야했습니다. 내가 볼 수있는 한 MSDN의 어느 곳에서나 사용할 수있는 7.0A 버전의 Windows SDK는 없습니다. 그러나 VS 2010을 설치하면 설치가 나타나고 Program Files \ Microsoft SDKs \ Windows에 7.0A regkey와 7.0A 폴더가 만들어집니다.

---

Visual Studio를 빌드 서버에 배치하는 데 어려움을 겪었습니다.

SDK v7.0A는 Visual Studio 2010과 함께 설치된 SDK입니다 (A는 이것이 VS 릴리스임을 나타냅니다). 그 이후로 최신 버전이 출시되었습니다. Windows 7 및 .NET Framework AKA v7.1 용 Microsoft Windows SDK .

내 빌드 서버에 이것을 설치했습니다. 그런 다음 Windows SDK 7.1 명령 프롬프트 (시작 => 모든 프로그램 => Microsoft Windows SDK 7.1)를 통해 SDK의 기본 버전을 7.1로 설정했습니다.

단계 :

cd Setup

WindowsSdkVer.exe -version:v7.1

LordHits의 의견을 포함하도록 편집하십시오 . 전체 SDK를 설치할 필요는 없습니다. ".NET 개발 / 인텔리 센스 및 참조 어셈블리"및 ".NET 개발 / 도구"옵션 만 설치하면됩니다.

---

값이 Off 인 GenerateSerializationAssemblies 매개 변수를 MsBuild에 전달하기 만하면됩니다.

msbuild.exe /p:GenerateSerializationAssemblies=Off

---

빌드 서버의 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"

---

최근 빌드 서버에서 비슷한 문제가 발생했습니다.

내 컴퓨터 (VS2010이 설치된)의 7.0A 폴더 (C : \ Program Files \ Microsoft SDKs \ Windows \ 7.0A)를 동일한 위치의 빌드 서버로 복사했습니다.

HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v7.0A 레지스트리 키를 만든 후 InstallationFolder를 C : \ Program Files \ Microsoft SDKs \ Windows \ 7.0A로 설정하십시오.

빌드 서버에서 레지스트리로 수행 할 작업에 대해 혼동되는 경우 VS2010이 이미 설치된 시스템에서 레지스트리를 참조 할 수도 있습니다.

---

VS 2010 Express 를 사용하고 Simmo의 답변 을 사용 하여 SDK 버전을 명시 적으로 설정 하려고 시도 했지만 동일한 오류가 발생했지만 WindowsSdkVer.exe (버전 설정 도구)는 Express를 대상으로하지 않는 것 같습니다 (제한되어 있기 때문에 이해할 수 없음) ).

Win 7 Prof에서 VS 2010 Express를 사용하고 있으며 항상 필요한 모든 exe가없는 Win SDK v7.0A를 사용하고 싶습니다. 현재 사용중인 버전을 명시 적으로 지정했는지는 중요하지 않습니다. WindowsSdkVer.exe (2010 Ex 만 설치되었지만 VS 2008 용으로 현재 버전의 SDK를 설정 한 것으로 계속보고합니다.)

그래서 싼 해결책 은 v7.0 WIN SDK (또는 v7.1과 같은 다른 버전)를 설치 하고 파일 시스템 폴더의 이름을 v7.0A로 바꾸는 것이 었습니다 . 기본적으로 VS 2010 Express에 거짓말했지만 지금은 작동합니다!

---

프로젝트 중 하나가 sgen.exe (서버 생성기)를 사용하여 웹 서비스를 생성합니다. 서버를 빌드하거나 프로젝트에서 웹 서비스 참조를 제거하려면 SDK를 설치해야합니다.

---

대상 파일이 도구 경로를 무시하고 있다고 생각합니다.이 파일을 간략히 살펴보고 거기에있는 일부 대상에서 SDKToolsPath를 $ TargetFrameworkSDKToolsDirectory로 설정합니다. 어쨌든 환경에서 이것을 설정해야한다고 생각하지는 않지만 프로젝트 파일에서 수정해야 할 수도 있습니다.

이 페이지에 따르면 http://nant.sourceforge.net/ Nant는 .Net 4.0을 지원하지 않습니다. 이것이 실제 문제 일 수 있습니까?

죄송합니다, 이것이 실제로 귀하의 질문에 대답하지 못한다는 것을 알고 있습니다.

---

실제로 SDK 버전 7.0A가 설치되어 있지 않습니까? 그것은 해결해야 할 문제입니다. VS2010 설치 로그 파일에서 무엇이 잘못되었는지 확인하십시오. SDK는 c : \ program files \ microsoft sdks \ windows \ 7.0a에 있어야하며 나열된 레지스트리 키도 있어야합니다. 6.0a 버전의 sgen.exe로 실행하는 것은 좋지 않습니다. 잘못된 컴파일러를 사용해야합니다.

---

설치 디렉토리 이외의 위치를 ​​지정 Sdk40ToolsPath하지 말고 설정하십시오 SdkToolsPath.

SDK를 설치하지 않고 빌드 시스템에 도구를 xcopi하여 일반적인 레지스트리 키가 없기 때문에 AL.exe와 비슷한 문제가 발생했습니다. 진단 출력 (/ verbosity : diagnostic)으로 빌드를 실행하고 Sdk40ToolsPath, Sdk35ToolsPath 및 SdkToolsPath와 같은 몇 가지 SDK 도구 경로가 정의되어 있음을 알았습니다. 적절한 SDK 버전의 bin 폴더를 가리 키도록 Sdk40ToolsPath를 설정하면 문제가 해결되었습니다.

---

새로운 Windows 10 컴퓨터에서 같은 문제가 발생했습니다. 내 설정 :

• 윈도우 10
• Visual Studio 2015 설치
• Windows 10 SDK

그러나 .NET 4.0 프로젝트를 빌드 할 수 없었습니다.

Aufgabe konnte "AL.exe"dem dem SdkToolsPath-Wert ""또는 dem registrierungsschlüssel "HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v8.0A \ WinSDK-NetFx40Tools-x86

Solution: After trying (and failing) to install the Windows 7 SDK (because thats also includes the .NET 4.0 SDK) I needed to install the Windows 8 SDK and make sure the ".NET Framework 4.5 SDK" is installed.

It's crazy... but worked.

---

I agree with IanS's answer. No need to install new SDK. Just make sure the registry key values SDK35ToolsPath and SDK40ToolPath for MSBuild are pointing to correct registry key values.

In my case my project was targeted for .NET 3.5 and I had to set SDK35ToolsPath for key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0 to $(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0A\WinSDKNetFxTools@InstallationFolder). And everything worked.

---

We have a winXP build pc, and use Visual Build Pro 6 to build our software. since some of our developers use VS 2010 the project files now contain reference to "tool version 4.0" and from what I can tell, this tells Visual Build it needs to find a sdk7.x somewhere, even though we only build for .NET 3.5. This caused it not to find lc.exe. I tried to fool it by pointing all the macros to the 6.0A sdk that came with VS2008 which is installed on the pc, but that did not work.

I eventually got it working by downloading and installing sdk 7.1. I then created a registry key for 7.0A and pointed the install path to the install path of the 7.1 sdk. now it happily finds a compatible "lc.exe" and all the code compiles fine. I have a feeling I will now also be able to compile .NET 4.0 code even though VS2010 is not installed, but I have not tried that yet.

---

ToolsVersion="4.0" does it for me in my MSBuild project:

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

---

I had this same issue and had installed Windows SDK 7.0 and Windows SDK 7.1 which neither fixed the issue. The cause of the problem for me was that the offending class library was built with Target Framework of .NET Framework 2.0.

I changed it to .NET Framework 4.0 and worked locally and when checked in the Build server built it successfully.

---

I had a similar issue, notably msbuild fails: MSB3086, MSB3091: "AL.exe", "resgen.exe" not found

On a 64 bits Windows 7 machine, I installed .Net framework 4.5.1 and Windows SDK for Windows 8.1.

Although the setups for the SDK sayd that it was up to date, probably it was not. I solved the issue by removing all installed versions of SDK, then installing the following, in this order:

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

---

Short answer: In the .csproj file, there is a way to specify the path to sgen.exe, using 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>

Your path may be different, but SGenToolPath is what you want.

For a list of other common MSBuild Project properties, see: https://msdn.microsoft.com/en-us/library/bb629394.aspx

We ended up using this SGenToolPath setting in the .csproj file, instead of editing the registry values on the build server. Editing the registry values on my local machine had worked as well, but was a bit more complicated and we didn't want to mess with the registry on the build server.

For the registry: In that case the problem was that the SDK40ToolsPath(s) under HKLM\SOFTWARE\Wow6432Node\Microsoft\MSBuild were pointing to a registry value $(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x86@InstallationFolder) which did not exist. I just replaced that with the actual path directly.

---

First make sure that you are already download dotNetFx40_Full_x86_x64.exe and installed(It's commonly bind with Visual Stdio).

Then quickly set a new Environment Variables at System variables. like below: "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.

---

Besides the registry mods, you may need to change version of the .net sdk your settings set to in Visual Studio.

I was having this problem and decided to check the project debug settings.

Project => Toolbar Properties => Debug Advance Compile Options button

The Target Framework (all configurations) was set to 3.0 which is not on my system.

I changed that to 4.0, then had to restart the project and Visual Studio 2010.

The project then built without errors and ran.

---

I had a similar problem. I had done a project using Visual Studio 2010 and then got the above error when i compiled it using Visual Studio 2012. I simple copied all the contents of C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A into C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A and that solved my problem.

---

I just had this error with a .sln file that was originally created in Visual Studio 2010 (and being built by Visual Studio 2010 and TFS 2010). I had modified the solution file to NOT build a project that was not supposed to be built in a particular configuration and visual studio changed the header of the solution file from:

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

Setting it back to the original 2010 version fixed my problem. I guess backwards compatibility in Visual Studio has still not been perfected.

---

try using visual studio's "repair". It worked for me.

---

CMD wrapper
I have tried all the stuff from here and even more. Nothing helped me.

I applied a CMD wrappers for MSBuild and DevEnv.com.
Main idea inside of such a wrapper is to make a prepared environment by calling Command Prompts from Visual Studio supply. And then pass the standard input parameters to a call of MSBuild or DevEnv.com.

Anyway, on my build-server now I can build projects from different Visual Studio versions.

How to use
I had to substitute calls to MSBuild and DevEnv by a call to my batch file wrappers.
And I didn't change any input parameters. As an example for my MSBuild wrapper call:

MsBuild_Wrapper.bat MySolution.sln /target Build /property:Configuration=Release

Ready solution
In fact, I got much more troubles with a migration from VS 2010 to VS 2015. But this one was the first and the toughest.
So, my modest rescue recipe for a Build Server is here. Possibly it is difficult to understand all this CMD style there from a first moment but any logic is obvious, I hope.

Hints
There are
MSBuild Command Prompt for Visual Studio and Developer Command Prompt for Visual Studio
I use them appropriately for MSBuild and DevEnv.com. But probably the MSBuild Command Prompt will be enough.

For VS 2015 those command prompts are here C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\. Or look through the Windows programs menu.

To pass all input parameters to MSBuild or DevEnv inside a batch file I used CALL MSBuild %*

---

I, too, encountered this problem while trying to build a plugin using Visual Studio 2017 on my horribly messed-up workplace computer. If you search the internet for "unable to find resgen.exe," you can find all this advice that's like 'just use regedit to edit your Windows Registry and make a new key here and copy-and-paste the contents of this folder into this other folder, blah blah blah.'

I spent weeks just messing up my Windows Registry with regedit, probably added a dozen sub-keys and copy-pasted ResGen.exe into many different directories, sometimes putting it in a 'bin' folder, sometimes just keeping it in the main folder, etc.

In the end, I realized, "Hey, if Visual Studio gave a more detailed error message, none of this would be a problem." So, in order to get more details on the error, I ran MSBuild.exe directly on my *.csproj file from the command line:

 "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"

Of course, you'll have to change the path details to fit your situation, but be sure to put 1) the complete path to MSBuild.exe 2) the complete path to your *.csproj file 3) the -fl -flp:logfile= part, which will tell MSBuild to create a log file of each step it took in the process, 4) the location you would like the *.log file to be saved and 5) ;verbosity=diagnostic, which basically just tells MSBuild to include TONS of details in the *.log file.

After you do this, the build will fail as always, but you will be left with a *.log file showing exactly where MSBuild looked for your ResGen.exe file. In my case, near the bottom of the *.log file, I found:

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"

So basically, MSBuild looked in five separate directories for ResGen.exe, then gave up. This is the kind of detail you just can't get from the Visual Studio error message, and it solves the problem: simply use regedit to create a key for any one of those five locations, and put the value "InstallationFolder" in the key, which should point to the folder in which your ResGen.exe resides (in my case it was "C:\Program Files\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools").

If you're a humanities major like myself with no background in computers, you may be tempted to just edit the heck out of your Windows Registry and copy-paste ResGen.exe all over the place when faced with an error like this (which is of course, bad practice). It's better to follow the procedure outlined above: 1) Run MSBuild.exe directly on your *.csproj file to find out the exact location MSBuild is looking for ResGen.exe then 2) edit your Windows Registry precisely so that MSBuild can find ResGen.exe.

---

I fixed it by passing this as command-line parameter to msbuild.exe:

Your mileage will vary depending on the SDK version you have on your system

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

참고URL : https://stackoverflow.com/questions/2731365/running-msbuild-fails-to-read-sdktoolspath