Can VS.NET 2010/MSBUILD produce XmlSerializers for .NET 3.5 SP1?

Question

I just upgraded a VS 2008 solution containing WinForms, general use libraries, and a web app to VS 2010, but all projects still target .NET 3.5 SP 1. I use this technique to generate XmlSerializers for my general use libraries. The WinForms app runs fine. When my web app tries to run using these libraries that reference the same XmlSerializers, it throws the following:

Server Error in '/WebSubscribers' Application. Could not load file or assembly 'Ceoimage.Basecamp.XmlSerializers' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.BadImageFormatException: Could not load file or assembly 'Ceoimage.Basecamp.XmlSerializers' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

I have looked at the XmlSerializer's references using .NET Reflector and see it references both the 2.0 and 4.0 versions of mscorlib as well as the 3.5 and 4.0 versions of System.Data.Linq. Strangely, it only uses the 4.0 version of System.Xml. That is probably my problem right there.

How can I get the web app to run using these XmlSerializers? When I simply delete those XmlSerializers, the web app runs fine. This is an option, but how can I force MSBUILD to create serializers for a specific version of the CLR?

Here is the MSBuild task I add to project files that forces the creation of the XmlSerializers:

<Target Name="AfterBuild" DependsOnTargets="AssignTargetPaths;Compile;ResolveKeySource" Inputs="$(MSBuildAllProjects);@(IntermediateAssembly)" Outputs="$(OutputPath)$(_SGenDllName)">
 <Delete Files="$(TargetDir)$(TargetName).XmlSerializers.dll" ContinueOnError="true" />
 <SGen BuildAssemblyName="$(TargetFileName)" BuildAssemblyPath="$(OutputPath)" References="@(ReferencePath)" ShouldGenerateSerializer="true" UseProxyTypes="false" KeyContainer="$(KeyContainerName)" KeyFile="$(KeyOriginatorFile)" DelaySign="$(DelaySign)" ToolPath="$(SGenToolPath)">
  <Output TaskParameter="SerializationAssembly" ItemName="SerializationAssembly" />
 </SGen>
</Target>

Answer 1

I found I can explicitly specify the SGEN task's tools path to use the 3.5 version, like so:

<SGen BuildAssemblyName="$(TargetFileName)" BuildAssemblyPath="$(OutputPath)" References="@(ReferencePath)" ShouldGenerateSerializer="true" UseProxyTypes="false" KeyContainer="$(KeyContainerName)" KeyFile="$(KeyOriginatorFile)" DelaySign="$(DelaySign)" ToolPath="C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin">

Answer 2

MSBuild 4 will (should...) use 3.5 tools to build 3.5 projects. However, it looks like it can't work out where the 3.5 tools are and is using the 4.0 tools. The result is that it is correctly building your 3.5 project (with CLR 2.0.50727 assemblies), but the 4.0 sgen.exe tool is generating Ceoimage.Basecamp.XmlSerializers.dll as a CLR 4.0.30319 assembly.

MSBuild uses the registry to get the path to the v3.5 tools. The MSBuild tasks that require v3.5 SDK tools will fall back to the v4.0 path if the path to the 3.5 tools can't be identified - look at the logic used to set the TargetFrameworkSDKToolsDirectory property in C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.NETFramework.props if you're really interested.

You can diagnose and fix possible registry problems as follows:

Install Process Monitor and set up a filter to monitor registry access by msbuild (Event class: Registry, Process Name: msbuild.exe, all types of result)

Run your build

Search Process Monitor for a RegQueryValue access matching "MSBuild\ToolsVersions\4.0\SDK35ToolsPath". Note that this could be be under either "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft" or "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft"

If you have a look at this key in the registry, you'll see that it aliases another registry value, e.g. "$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx35Tools-x86@InstallationFolder)" Shortly after this, you'll probably see a "NAME NOT FOUND" result as msbuild tries to load the value from the key specified.

It should be clear which keys you need to add / amend from here.

There are a few possible reasons why the registry values are wrong. In my case, an issue with the Microsoft SDK v7.1 installation meant that the registry keys were named incorrectly, which has been identified as a bug here:

http://connect.microsoft.com/VisualStudio/feedback/details/594338/tfs-2010-build-agent-and-windows-7-1-sdk-targeting-net-3-5-generates-wrong-embedded-resources

Answer 3

Are you reliant on anything 4.0 specific?

If you invoke MSBuild 4.0, you'll get 4.0 tools. If you invoke MSBuild 3.5, you'll get 3.5 tools (which is what you want as you're clearly hosting in a 2.0 CLR).

The other option is to put the 4.0 CLR on your web server. If that's not open, you shouldnt have any 4.0 targetted stuff in your stream.