Team Build 2008 to 2010 – Notes on the side of migration

Here are just my few notes in a very raw format, hope someone might find it useful. The context – trying to run builds as they are without transforming them or modifying build type .proj file anyhow.

Environment: Windows 2008 x64 VM, Team build 2008 installed, newly installed Team build 2010. Projects do build under team build 2008.

From build log following is used by the agent to invoke msbuild:

Run TfsBuild for Configuration Folder

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe /nologo /noconsolelogger "C:\xyz\BuildType\TFSBuild.proj" /m:1 "@C:\xyz\BuildType\TfsBuild.rsp"

So we can see the x64 msbuild is picked up and later on few issues raise from it.

But first stop was at the System.Workflow.xyz family. Build started to pick version 4.0 from innocently looking references in the csproj:

    <Reference Include="System.Workflow.Activities" />

    <Reference Include="System.Workflow.ComponentModel" />

    <Reference Include="System.Workflow.Runtime" />

That was easy to fix by providing the stronger references, like:

<Reference 
Include="System.Workflow.Activities, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />    

<Reference 
Include="System.Workflow.ComponentModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />   

<Reference 
Include="System.Workflow.Runtime, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

Next stop – sgen for binaries compiled as x86:

C:\yuy\x64\sgen.exe /assembly:"zzz.exe" /proxytypes ....
.....
Could not load file or assembly 'file:///C:\XYZ\zzz.exe' or one of its dependencies. 
An attempt was made to load a program with an incorrect format.

Why on earth would you have your code compiled specifically as x86? Here is the point: because of nasty x86 specific dependencies like Infragistics or Oracle.DataAccess.dll of certain versions. So when you run your any cpu binaries, they get into x64 loader and fail then on your unfortunate x86 only dependencies.

Anyway this is solved easily by just giving up the compile time serialization assembly generation and letting .NET to generate it during runtime. Just put:

<GenerateSerializationAssemblies>Off</GenerateSerializationAssemblies>

To a PropertyGroup of your project corresponding to the target configuration (or the top one to affect all configurations).

This is what I have gathered for a moment.