TFS 2010 Build Agent and Windows 7.1 SDK targeting .NET 3.5 generates wrong embedded Resources - by Matthias Greim

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


4
0
Sign in
to vote
ID 594338 Comments
Status Closed Workarounds
Type Bug Repros 4
Opened 9/3/2010 4:40:28 AM
Access Restriction Public

Description

What happens is, that during the build the SDK35ToolsPath is not set and so MSBuild uses the NETFX 4.0 Tools version. This in turn makes ResGen generate resources that point to the System.Drawing Version 4.0.0.0 assembly. 

This all is caused by the fact, that HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\SDK35ToolsPath points to $(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx35Tools-x86@InstallationFolder), but the Windows 7.1 SDK only installs the keys WinSDKNetFx35Tools and WinSDKNetFx35Tools-x64. Notice the missing dash and that there is no -x86 entry. The 7.0A SDK that ships with Visual Studio 2010 names its registry keys the right way.
Sign in to post a comment.
Posted by drdrdrdr on 1/29/2013 at 5:30 AM
On 64bit machines it is important to perform the workaround on the Wow6432Node as well!
See also: http://stackoverflow.com/questions/6096276/what-decides-the-target-framework-version-of-a-satellite-assembly for more information!
Posted by Joel 'Jaykul' Bennett on 5/7/2012 at 11:12 AM
Microsoft seems to have screwed up the workaround here too, there is no "WinSDKNetFx35Tools-86" (at least on our boxes). The workaround posted on the workaround tab is right though...
Posted by Microsoft on 1/17/2011 at 4:39 PM
There is an error in the registry paths for the Windows 7.1 SDK.

The workaround for this issue would be:

Export HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDKNetFx35Tools and reimport as WinSDK-NetFx35Tools

Export HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDKNetFx35Tools-86 and reimport as WinSDK-NetFx35Tools-x86

Export HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDKNetFx35Tools-x64 reimport as WinSDK-NetFx35Tools-x64

Posted by Matthias Greim on 9/6/2010 at 12:03 AM
I just submitted a small demo with an msbuild script together with the binaries produced by a machine running SDK 7.0A (VS2010) and the one with the SDK 7.1 only. Notice that the problem does not seem to be related to TFS but only to the diffent SDK versions.
Another thing to mention is, that the script uses msbuild 4.0 and Tool Version 4.0 to build a 3.5 binary. But as I said, it works on a VS2010 machine.
Posted by Microsoft on 9/5/2010 at 8:06 PM
Thanks for reporting the issue.
In order to fix the issue, we must first reproduce the issue in our labs. We are unable to reproduce the issue with the steps you provided.

Could you please attach a zipped project file to this feedback through our site to help us reproduce the issue?

Thanks again for your efforts and we look forward to hearing from you.
Visual Studio Product Team
Posted by Microsoft on 9/3/2010 at 5:01 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)