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>

Maris

you should add that edit as an answer so we can vote it up, it appears to be the best solution :) – Purgatorial

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">

Maris

Are you changing the targets file or are you modifying your project files some how? I don't know how to apply this to my environment... – Czarism

This was a long time ago, but I am pretty sure I edited the CSPROJ file directly. – Maris

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

Millet

Thanks for this answer. I'm combining this with https://mcmap.net/q/119642/-running-msbuild-fails-to-read-sdktoolspath to solve my problem – Latterly

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.

Making

I just checked one of my projects and found it only references 2.0 and 3.5 framework assemblies. One thing I notice, however, is that the Specific Version property of each framework references to false. When I unload a project and peek into the .CSPROJ file, the property tag does mention the 4.0 tools like so: <Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0"> When I change the ToolsVersion to 3.5, VS 2010 converts the project and returns the value to 4.0. – Maris

@flipdoubt: The VS2010 forcing 4.0 toolsversion is a known issue (have a search). the problem here is the SGen task being imported is the 4.0 sgen task which will default to the 4.0 SGen.exe Perhaps putting a ToolPath override to the 3.5 SGen mioght work. – Making

And then I looked at your edit. I think that's the best fix given that running your ToolsVersion 4.0 projects through MSBuild 3.5 isnt going to be a long term solution – Making