Howdy, I'm having a bit of an issue runnning a NAnt script that used to properly build my .Net 2.0 based website, when compiling with VS2008 and it's associated tools. I've recently upgraded all the project/solution files to VS2010, and now my build fails with the following error:
[exec] C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets(2249,9): error MSB3086: Task could not find "sgen.exe" using the S dkToolsPath "" or the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A". Make sure the SdkToolsPath is set and the tool exists in the correct processor specific location under the SdkToolsPath and that the Microsoft Windows SDK is installed
Now, I DO have prior versions (.Net 3.5) of the Windows SDK installed on the build server, and the full .Net 4.0 framework is installed, but I've not run across a .Net 4.0 specific version of the Windows SDK.
After a bit of experimentation and research, I finally just setup a new environmental variable "SDKToolsPath" and pointed it to the copy of sgen.exe in my windows 6.0 sdk folder. This generated the same error, but it got me to notice that even though the SDKToolsPath environmental variable IS set (confirmed that I can "echo" it at the command line and it has the expected value), the error message seems to indicated that it's not being read (note the empty quotes).
Most of the information I've found is .Net 3.5 (or earlier) specific. Not much 4.0 related out there yet. Searching for error code MSB3086 generated nothing useful either. Any idea what this might be?
Scott
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.
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.
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
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 suspect the targets file is overriding the tools path, I had a quick look in this file and is sets the SDKToolsPath to $TargetFrameworkSDKToolsDirectory under some of the targets in there. I don't think you should need to set these in the environment anyway, but they may need fixing in your project files.
Note that according to this page http://nant.sourceforge.net/ Nant does not support .Net 4.0, could this be the real problem?
Sorry, I know this doesn't really answer your question:(
You don't actually have SDK version 7.0A installed? That's a problem you'll need to fix. Look in the VS2010 install log files to see what went wrong. The SDK should be present in c:\program files\microsoft sdks\windows\7.0a and the listed registry key must be present as well. Running with the 6.0a version of sgen.exe isn't okay, it is bound to use the wrong compiler.
try using visual studio's "repair". It worked for me.
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.
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.
I manually pass the variables to MSBuild on build server.
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"
Set Sdk40ToolsPath rather than SdkToolsPath to specify a location other than the install directory.
I hit a similar problem with AL.exe because I had just xcopied the tools onto the build machine rather than installing the SDK, so the usual registry keys were missing. I ran a build with diagnostic output (/verbosity:diagnostic) and noticed that there were several SDK tools paths defined: Sdk40ToolsPath, Sdk35ToolsPath and SdkToolsPath. Setting Sdk40ToolsPath to point to the appropriate SDK version's bin folder solved the problem for me.
I've run into the same error but in a different situation: using VS 2010 Express and trying to use Simmo's answer to explicitly set the SDK version - however WindowsSdkVer.exe (version setter tool) seems to not target Express (understandable since it's limited).
I'm using VS 2010 Express on Win 7 Prof. and it always wants to use v7.0A of the Win SDK (which does not have all the needed exes), and it deosn't matter which version I explicitly set as current using WindowsSdkVer.exe (It keeps reporting it set the current version of the SDK but for VS 2008 although though I only have 2010 Ex installed. )
So my cheap workaround was to install v7.0 WIN SDK (or another version like v7.1) and then rename its file system folder to v7.0A - basically I just lied to VS 2010 Express but it works now!
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.
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 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
I couldn't face putting Visual Studio on the build server.
The SDK v7.0A is the SDK installed with Visual Studio 2010 (The A indicates this is a VS release). Since then, a newer version has been released. Microsoft Windows SDK for Windows 7 and .NET Framework AKA v7.1.
I've installed this on my build server. And then via the Windows SDK 7.1 Command Prompt (Start => All Programs => Microsoft Windows SDK 7.1), I set the default version of the SDK to be 7.1.
Steps:
cd Setup
WindowsSdkVer.exe -version:v7.1
Edit to include LordHits' comment: one doesn't need to install the entire SDK. Installing just the ".NET Development/Intellisense and Reference Assemblies" and ".NET Development/Tools" options is enough.
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.
I encountered a similar issue just recently on our build server.
I copied the 7.0A folder (C:\Program Files\Microsoft SDKs\Windows\7.0A) from my computer (which has VS2010 installed) on it to the build server in the same location.
After create the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A. Set InstallationFolder to C:\Program Files\Microsoft SDKs\Windows\7.0A.
You can also reference the registry on your machine with VS2010 already installed on it if you are confused about what to do with the registry on the build server.
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.
Simply pass GenerateSerializationAssemblies parameter with value Off to your MsBuild.
msbuild.exe /p:GenerateSerializationAssemblies=Off
One of your projects use sgen.exe (Server Generator) to generate web service. you need install SDKs to Build Server or remove Web Service references from the project.
I had the same issue on a brand new Windows 10 machine. My setup:
But I couldn't build .NET 4.0 projects:
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
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.
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">
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 %*
Source: Stackoverflow.com