Why is Visual Studio 2013 using the wrong SdkToolsPath for lc.exe?

Question

I am using Visual Studio 2013 with an asp.net project. One of the projects gives an error below. Why is he looking for LC.exe in the wrong way? My Windows 8.1 SDK is installed and I have lc.exe on

C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools 

and 64-bit version, and I have a registry key

 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.1A 

I am considering Microsoft.Common.targets under C:\Windows\Microsoft.NET\Framework\v4.0.30319 , and this key exists: SdkToolsPath="$(TargetFrameworkSDKToolsDirectory)" . Then looked at Microsoft.NetFramework.CurrentVersion.props under

 C:\Program Files (x86)\MSBuild\12.0\Bin 

and TargetFrameworkSDKToolsDirectory defined in $SDK40ToolsPath . According to MSBuild /v:diag ,

 SDK40ToolsPath = C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools 

which looks good. Project goal in VS in .NET 4.0.

So why is he still looking for the wrong folder or registry key? Interestingly, when I rebuild the project after receiving an error message, the project is being built perfectly.

 Error 5 Task could not find "LC.exe" using the SdkToolsPath "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\" or the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x86". 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 C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets 2428 5 SuperReports 

Answer 1

Turns out you can specify the SDK path directly in the .csproj file:

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

and the found construction is found in this way.

Earlier, I was supposed to install this with <SdkToolsPath> , but that didn't work. In Microsoft.Common.targets, SdkToolsPath is installed from TargetFrameworkSDKToolsDirectory, so I tried this and it worked. This is on Visual Studio 2015, and msbuild is called from ant.

Solution found through MSBuild. Using the wrong version of sgen.exe to generate the XmlSerializer DLL?

Answer 2

Do you have a PlatformToolset property defined in your project before importing? I think he uses this and possibly the ToolsVersion attribute in the project XML element to choose between several installed SDKs. I think, from a similar way, a funny business is that the IDE sets up paths to find things based on PlatformToolset that it looks for in a specific place in the project (when building from the MSBuild command line, it works no matter how it was installed).

Here is an example from the vcxproj file:

 <?xml version="1.0" encoding="utf-8"?> <Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <!-- NB: see ToolsVersion in above --> ⋮ <PropertyGroup Label="Globals"> <ProjectGuid>{⋯⋯⋯}</ProjectGuid> <RootNamespace>blahblahblah</RootNamespace> <ConfigurationType>StaticLibrary</ConfigurationType> <PlatformToolset>Windows7.1SDK</PlatformToolset> <!-- NB: PlatformToolset must be repeated in each top-level project file --> <Keyword>Win32Proj</Keyword> </PropertyGroup> 

I think that there are two reasons why this gives funny results if they are placed on a common property page: firstly, it must be installed before standard built-in logic is imported (for example, Microsoft.Cpp.Default.props ), and secondly, the IDE somehow sets the paths on its own or does something with the created solution file, and it looks for this property in the main file. I found out about this when I had the wrong paths (the wrong version of the EXE was used) when building by pressing F7 , when it worked fine, invoking MSBuild from the command line.

In the IDE, check the "Platform Toolbox" checkbox in the property editor for the project. Make sure it is displayed in bold ; that is, install right there, and not be inherited, even if it has the correct version.

Answer 3

I went with a slightly different hack than the one suggested by Hans Passant above. My scenario - my builds are done through Jenkins (CI tool) using MSBuild 2015 on a Windows 2008 server.

Microsoft SDK 10 does not support Windows 2008, according to the docs. I tried playing with the SdkToolsPath and FrameworkOverride msbuild command-line SdkToolsPath , but to no avail (I did not try them together, I just realized when typing).

In any case, something that worked was that yes - I could not get msbuild to use a newer version of the SDK instead of the one from Windows 7 (he insists on taking LC.exe with C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\NETFX 4.0 Tools ), so I had to rewrite LC.exe using SDK 10 (I installed it on my local computer, and not on a build server running Windows 2008).

My build finally succeeded.