What decides the target framework version of a satellite assembly?

Question

What decides the target framework version of a satellite assembly?

Looking at the log file I can see the satellite assembly is build by running ResGen.exe and Al.exe but I can't find out what decides the target framework of the resulting assembly.

Background

I'm trying to resolve a problem where a satellite assembly gets targeted for the .NET 4.0 runtime when I build it on the build server but targeted for .NET 2.0 runtime when I compile it on my development computer. The rest of the solution is targeted for .NET 2.0 runtime and the executable will not load the satellite assembly if it is targeted for .NET 4.0 runtime.

I have tried building the project "manually" using msbuild on the build server which also results in a satellite assembly targeted for .NET 2.0 runtime.

I only get the wrong target runtime version of 4.0 when I build using the automated build server.

Millimeter

Answer 1

I just spent the whole day tracking this down, but I think I have it solved. Yes, I am a martyr. Benefit from the findings of misfortunate adventure!

My best guess is that the Windows 7.1 SDK installation seems to have a bug in it regarding the registry keys it adds. Some of the registry values point to 7.0a when it should point to 7.1. Additionally, some of the registry keys are incorrectly named.

After some manual changes, my resource DLLs were back to compiling to the appropriate target version of the framework. I'm pretty sure an x64 version would not be patched with my changes. Use at your own risk!

I personally am not too happy with having a hacked up registry for our build server, though. Who knows what other horrors await me at runtime on my server builds. I'm considering just installing Visual Studio 2010.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx35Tools]
"InstallationFolder"="C:\\Program Files\\Microsoft SDKs\\Windows\\v7.1\\bin\\"
"ProductVersion"="7.1.7600.0.30514"
"ComponentName"="Microsoft Windows SDK NetFx 3.5 Tools"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx35Tools\1033]
"SP"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx35Tools-x86]
"InstallationFolder"="C:\\Program Files\\Microsoft SDKs\\Windows\\v7.1\\bin\\"
"ProductVersion"="7.1.7600.0.30514"
"ComponentName"="Microsoft Windows SDK NetFx 3.5 Tools"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx35Tools-x86\1033]
"SP"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0]
"MSBuildToolsPath"="c:\\WINDOWS\\Microsoft.NET\\Framework\\v4.0.30319\\"
"MSBuildToolsRoot"="c:\\WINDOWS\\Microsoft.NET\\Framework\\"
"FrameworkSDKRoot"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1@InstallationFolder)"
"MSBuildRuntimeVersion"="4.0.30319"
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\WinSDK-NetFx40Tools-x86@InstallationFolder)"
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\WinSDK-NetFx35Tools-x86@InstallationFolder)"
"MSBuildToolsPath32"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MSBuild\\ToolsVersions\\4.0@MSBuildToolsPath)"

Nuncupative

Your workaround did work for me. There is a similar official workaround posted on Microsoft Connect. It does not include the changes of v7.0A to v7.1 for MSBuild. Those changes were necessary to get it to work on my build machine. Thanks a lot! – Millimeter

I can confirm this fixes the issue (or at least did for me). For some reason all but the last edit - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0 - were already done so I just had to finish the rest and boom, all my satellite assemblies now play nice with my app. – Alford

Worked like a charm. I did had to add the same rules for the Wow3264Node on my system, but after that my build targetted the right framework again. – Brogdon

Answer 2

Ran into same problem today. The reason seems to be that some required environment variables were not set.

Previously, the build command on my build server was simply "C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe"

I created the batch file containing two lines:

@call "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\setenv.cmd"
@C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe %* 

and configured the server to use this batch file as a build command.

My build server was Jenkins, not TFS, but I hope this will solve your problem as well.

Perceive

Answer 3

How is the automated build setting up the command environment where MSBuild is executed? If you can figure that out, and see how it is different from how you set up the command environment when you "manually" had a successful build on the same machine, you will likely find the answer. If you can't find these clues, set the build to log with diagnostics (/fl /flp:v=diag;logfile=build-diag.log) and diff the auto vs. manual build log.

Milklivered

Answer 4

In addition to Johnny Kauffman's answer, I had the problem that I had a subkey in HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0 named 11.0. In this key were references to HKLM\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0A which doesn't exist on my machine. So if Johnny Kauffman's answer doesn't help, check for the 11.0 key and consider removing it.

Mildred