Running MSBuild fails to read SDKToolsPath
Asked Answered
S

25

134

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

Suellensuelo answered 28/4, 2010 at 16:30 Comment(1)
Related issue in this post. I posted an answer there as well. #1110455Faxun
U
15

I had to bite the bullet and install VS 2010 on our build server to fix this issue. As far as I can see, there's no 7.0A version of the Windows SDK available anywhere on MSDN. However, installing VS 2010 appears to install it, creating a 7.0A regkey and a 7.0A folder in Program Files\Microsoft SDKs\Windows.

Uppsala answered 29/4, 2010 at 16:43 Comment(15)
Yes, I eventually did that as well and it solved my issue. But I'm not thrilled about having the entire VS2010 environment on my build server when it seems that there should simply be a downloadable version of the 7.0a Windows SDK. Would love to know the URL if anyone has it available.Suellensuelo
microsoft.com/downloads/… this is SDK ver. 7. Isn't it?Popeyed
Yes, but it is not Version 7.0a, and that is important here. There's an interesting workaround posted here, haven't tried it myself though: #1110455Uppsala
I prefer not to install Visual Studio 2010 on a server. I prefer Simmo's suggestion below of setting the current Windows SDK to v7.1. WindowsSdkVer.exe is located in C:\Program Files\Microsoft SDKs\Windows\v7.1\Setup (assuming it was installed to C:\Program Files).Lucindalucine
I have found that if you only install Windows SDK 7.1 and .NET 4.0. MSBuild does not set proper paths to SDK40ToolsPath and SDK35ToolsPath. To fix it, I had to change a few entries in 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)" Similarly change "v7.0A" to "v7.1" in SDK35ToolsPath and FrameworkSDKRoot.Modena
Sheesh -- I ran into the same problem again myself, googled for it and found my own answer! :) Something seems to have reset my change and I guess I have to manually apply it again.Modena
Just did @BlueMonkMN's idea, hope it sticks now that I see it might happen again.Windywindzer
In addition to the changes @Modena made, I also needed to change the CurrentInstallFolder location in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\WindowsBushwa
ARRRGH! The latest .NET 4.0 patches (2011-08-11) overwrote these registry settings!Mirna
@Modena - Don't you just love it when that happens :)Mirna
Double ARRGGGHH! The latest .NET 4.0 patch (2012-01-10) overwrote the registry entries again!Mirna
I had to additionally change WOW64 keys. Just do a registry search for v7.0A and replace with v7.1Backfill
Update on my earlier response. It appears that on 64-bit OSes, it may also be necessary to update similar values in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSBuild\ToolsVersions\4.0, and it may be necessary to install the 8.0 SDK or update the values in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\11.0 and HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSBuild\ToolsVersions\4.0\11.0 I did all of the above except installing the 8.0 SDK, and was unable to compile until I (as one batch step) included my updates to all the 4.0\11.0 nodes.Modena
I ran into this with resgen and a 64-bit OS. I had to copy over c:\program files (x86)\microsoft SDKs\Windows\v7.0a from my dev machine, modify the registry with the keys at HKLM\SOFWARE\Microsoft\Microsoft SDKs\Windows\v7.0A and then also include those same keys under HKLM\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v7.0AResidual
This absolutely makes zero sense, but I got this working by building the project once with the incorrect msbuild "C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe" myproj.vbproj, then the correct one worked afterwards :"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe " myproj.vbprojAnglicize
E
227

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.

Expertism answered 25/5, 2010 at 17:44 Comment(11)
This worked perfectly for me, combined with copying across the files into C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications from my VS machine.Helvetia
I was facing the same problem as the original author and this answer solved it! I did not have to install Visual Studio 2010 on my Build machine.Inconsistent
Also, just to clarify, 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. This and copying the files from dnolan's comment.Olivette
Thanks for this solution, it worked perfectly for me on our build server! FYI- for anyone who may be questioning, the build server is Windows Server 2008 x64.Windblown
Thanks so much for this answer; ran into same issue at work with this as well.Pryor
This worked for me... and I am using a Windows XP build machine.Demesne
In order to have my TeamCity run MSBuild 4.0 while still generating 2.0 satellite assemblies, I had to set ResGenExecuteAsTool: #12355125Alleviate
This worked for me too. This answer should be set as correct. Installing VS on a build server is terrible solution.Castara
Deleting HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A from the registry helped.Gerundive
Microsoft Windows SDK for Windows 7 and .NET Framework AKA v7.1 doesn't install on win10. The message is "Some Windows SDK components require the RTM .NET Framework 4. Setup detected a pre-release version of the .NET Framework 4. If you continue with Setup, these components will not be installed"Ruthenic
The link is brokenTashia
R
23

Simply pass GenerateSerializationAssemblies parameter with value Off to your MsBuild.

msbuild.exe /p:GenerateSerializationAssemblies=Off
Retreat answered 5/9, 2013 at 5:12 Comment(5)
msbuild.exe /p:GenerateSerializationAssemblies=OffRetreat
Or set "Generate serialization assembly: Off" in the Build tab of the web service's project properties.Globule
What does this do exactly?Gradient
GOTCHA: If you turn it off on the build tab, make sure you do this for the build configuration that is relevant, (DropDown at top of Build tab) in my case it was just the build server with the issue, so I had to change this in the 'Release' configuration.Grosmark
I love just randomly switching build flags with no clue what they actually do.An
N
18

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"
Nyctalopia answered 9/6, 2017 at 7:27 Comment(1)
This is what I ended up doing for a Windows 10 SDK in a server with no Visual Studio and Build Tools 2019. None of the other solutions seemed to help and this one did the trick in a clean way.Szymanowski
U
15

I had to bite the bullet and install VS 2010 on our build server to fix this issue. As far as I can see, there's no 7.0A version of the Windows SDK available anywhere on MSDN. However, installing VS 2010 appears to install it, creating a 7.0A regkey and a 7.0A folder in Program Files\Microsoft SDKs\Windows.

Uppsala answered 29/4, 2010 at 16:43 Comment(15)
Yes, I eventually did that as well and it solved my issue. But I'm not thrilled about having the entire VS2010 environment on my build server when it seems that there should simply be a downloadable version of the 7.0a Windows SDK. Would love to know the URL if anyone has it available.Suellensuelo
microsoft.com/downloads/… this is SDK ver. 7. Isn't it?Popeyed
Yes, but it is not Version 7.0a, and that is important here. There's an interesting workaround posted here, haven't tried it myself though: #1110455Uppsala
I prefer not to install Visual Studio 2010 on a server. I prefer Simmo's suggestion below of setting the current Windows SDK to v7.1. WindowsSdkVer.exe is located in C:\Program Files\Microsoft SDKs\Windows\v7.1\Setup (assuming it was installed to C:\Program Files).Lucindalucine
I have found that if you only install Windows SDK 7.1 and .NET 4.0. MSBuild does not set proper paths to SDK40ToolsPath and SDK35ToolsPath. To fix it, I had to change a few entries in 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)" Similarly change "v7.0A" to "v7.1" in SDK35ToolsPath and FrameworkSDKRoot.Modena
Sheesh -- I ran into the same problem again myself, googled for it and found my own answer! :) Something seems to have reset my change and I guess I have to manually apply it again.Modena
Just did @BlueMonkMN's idea, hope it sticks now that I see it might happen again.Windywindzer
In addition to the changes @Modena made, I also needed to change the CurrentInstallFolder location in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\WindowsBushwa
ARRRGH! The latest .NET 4.0 patches (2011-08-11) overwrote these registry settings!Mirna
@Modena - Don't you just love it when that happens :)Mirna
Double ARRGGGHH! The latest .NET 4.0 patch (2012-01-10) overwrote the registry entries again!Mirna
I had to additionally change WOW64 keys. Just do a registry search for v7.0A and replace with v7.1Backfill
Update on my earlier response. It appears that on 64-bit OSes, it may also be necessary to update similar values in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSBuild\ToolsVersions\4.0, and it may be necessary to install the 8.0 SDK or update the values in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\11.0 and HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSBuild\ToolsVersions\4.0\11.0 I did all of the above except installing the 8.0 SDK, and was unable to compile until I (as one batch step) included my updates to all the 4.0\11.0 nodes.Modena
I ran into this with resgen and a 64-bit OS. I had to copy over c:\program files (x86)\microsoft SDKs\Windows\v7.0a from my dev machine, modify the registry with the keys at HKLM\SOFWARE\Microsoft\Microsoft SDKs\Windows\v7.0A and then also include those same keys under HKLM\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v7.0AResidual
This absolutely makes zero sense, but I got this working by building the project once with the incorrect msbuild "C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe" myproj.vbproj, then the correct one worked afterwards :"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe " myproj.vbprojAnglicize
A
8

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.

Amsterdam answered 6/1, 2011 at 22:54 Comment(1)
For me, Simmo's answer didn't work - this registry hack did though (Win 2K3 SP2).Bradawl
Z
7

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!

Zorina answered 16/10, 2010 at 23:34 Comment(0)
S
5

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.

Seisin answered 12/5, 2011 at 16:6 Comment(2)
Or set "Generate serialization assembly: Off" in the Build tab of the web service's project properties.Globule
GOTCHA: If you turn it off on the build tab, make sure you do this for the build configuration that is relevant, (DropDown at top of Build tab) in my case it was just the build server with the issue, so I had to change this in the 'Release' configuration.Grosmark
D
5

I had the same issue on a brand new Windows 10 machine. My setup:

  • Windows 10
  • Visual Studio 2015 Installed
  • Windows 10 SDK

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.

Delagarza answered 17/11, 2015 at 9:59 Comment(1)
This exactly helped me on Windows 10 too.Strahan
A
4

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:(

Aether answered 28/4, 2010 at 16:44 Comment(1)
Correct, NAnt doesn't support the project/solution file formats for VS2010 yet, which is why I'm calling out to MSBuild for the actual compilation step. Will check out the targets file.Suellensuelo
C
3

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.

Cranky answered 28/4, 2010 at 18:45 Comment(2)
Remember, this is a build server, so installing the complete VS2010 environment wasn't my first choice. I was unable to find any available download of the Windows SDK 7.0aSuellensuelo
I don't see the problem. Running a build on a machine who's configuration doesn't match the dev machines, that's a problem that will wear you out quickly.Cranky
B
3

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.

Boson answered 1/7, 2010 at 11:55 Comment(3)
Where did you set Sdk40ToolsPath ?Ruthenic
I would assume that it needs to be added to the environment path. However, it didn't work for me.Evolution
Sorry this was so long ago I've forgotten the details, but I think it was either an environment variable or set in the MSBuild project file. Also note that the original question relates to .NET Framework 4.0 / VS2010 but different variables may be needed for later framework versions.Boson
F
2

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.

Friendship answered 15/12, 2010 at 21:28 Comment(0)
O
2

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.

Optician answered 4/4, 2012 at 21:28 Comment(0)
I
2

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">
Immoral answered 26/2, 2013 at 3:20 Comment(1)
Well, in my case I used ToolsVersion="14.0" for VS 2015 and this solved the issueMoynahan
E
2

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.

Edina answered 27/2, 2018 at 6:2 Comment(1)
This is solving the problem. Just a hint if anyone has the same problem as I. The Env Variable need to be called TargetFrameworkSDKToolsDirectory and not SdkToolsPath !!!Englert
G
2

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
Gariepy answered 28/8, 2019 at 19:42 Comment(0)
J
1

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.

Jenniejennifer answered 22/1, 2013 at 0:44 Comment(0)
I
1

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

Ingaingaberg answered 30/9, 2014 at 14:53 Comment(0)
B
1

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

Begrime answered 22/2, 2016 at 8:47 Comment(0)
G
1

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.

Grace answered 18/5, 2016 at 0:51 Comment(0)
Q
1

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.

Qianaqibla answered 18/6, 2019 at 0:49 Comment(8)
I tried this but for some reason I don't get the list of paths that you display. I found a similar post to yours on this site: community.sdl.com/developers-more/developers/… so I know that it should work, but no avail. What version of MSBuild are you using?Schnozzle
Looks like I am using MSBuild version 4.0.30319. I also have version 3.5, 3.0, and 2.0.50727 installed on this computer. I tried to run those versions of MSBuild on my *.csproj file (in the same fashion as outlined above), but it didn't work...didn't even create a *.log file. /// When you run MSBuild on your *.csproj file, is the computer at least producing a *log file? My understanding is that there is a log file, just no specific information regarding the paths that were searched when looking for ResGen.exe--is that correct?Qianaqibla
Looks like I have the same version of MSBuild (4.0.30319). And yes, you are right. I am getting a log file, but it doesn't give any information on Registry paths. Which of the five paths you post above did you end up using?Schnozzle
I used the 1st path on the list--just added an "InstallationFolder" in the key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6.2\WinSDK-NetFx40Tools-x86. Also, the *.log file is actually extremely long--thousands of lines, in my case. I couldn't find the path information with my naked eye. I ended up opening the *.log file in Notepad and searching for "ResGen.exe," which brought the pertinent area (paths information) to my attention.Qianaqibla
OK thanks. Yes I'm using Notepad++ and searched it up and down. Doesn't build still for me. Looks like it gets to Compiling plug-in resources as (Task ID:35), which is compiling plug-in manifest and then fails with the error of Failed to locate ResGen.exe. It doesn't make it to 41 as you have in your output above. Thanks for your help!Schnozzle
Thank you, best of luck. The world of Trados Studio plugin development is murky at best, but if / when you can get a *.sdlplugin file to magically pop out after a compile, congratulations!Qianaqibla
Hey, just thought you might want to know I managed to get my plug-in to compile. It took a bit more work, but it finally worked somewhat randomly one day! Your post definitely helped. Cheers!Schnozzle
Super--congratulations! You've become one of a handful of people (a few hundred, I would guess) who've fought through the errors and mystery and actually successfully compiled a plugin for Trados. Good luck with your plugin publishing, see you on the SDL Appstore!Qianaqibla
G
0

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.

Goforth answered 20/1, 2012 at 0:10 Comment(2)
I made a mistake it's locate at the following. Project => Toolbar Properties => Compile Advance Compile Options button I also created a new project and the new project .net was set to 3.0. So there will be a need to change the default setting as well. Scott A. ToveyGoforth
I found out that when you create a project, at the top of the window there is a drop down list of all the frameworks. Everything is listed regardless of whether it is installed or not. Once you select a framework and create a project from that list, it remains the default until you change it to another framework for a new project. This is a bit reckless, the list should only contain frameworks that are installed on the system.Goforth
U
0

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.

Unamuno answered 19/10, 2015 at 13:41 Comment(1)
I wish there was a vote for worlds worst solution. This would be it.Nall
P
0

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.

Pahl answered 16/12, 2015 at 19:32 Comment(0)
S
0

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 %*

Seaden answered 21/1, 2017 at 21:4 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.