Your custom assemblies need update, or else, redirecting

As part of making sure TFS server upgrade experience is enjoyable, your existing build definitions are supposed to work correctly with the new TFS 11 Beta build machines. However, as much as we wanted to cover, there is still something that is not fulfilled out of the box. For those who customize the build process with custom activities that make use of the Team Foundation Object Model, especially the Microsoft.TeamFoundation.Build.* assemblies, upgrading your server and build machines to TFS 11 requires a little manual intervention (and I would argue that it is something that you eventually want to do anyway).

So what is the problem?

Your awesome custom activities were built against TFS 2010 bits. Loading your custom assemblies in the TFS 11 build service process triggers loading TFS 2010 assemblies, and the Workflow Foundation (WF) services are not happy about that. Why?

The build process template, for a particular reason, references the TFS OM assemblies by their simple names. When there are more than one version of the same assembly present in the process, the WF services, while loading and validating the build workflow, attempts to resolve the simple-name references with best effort, and in this case it decides to fail with a namespace ambiguity error.

Here’s what you likely see when this issue occurs:

TF215097: An error occurred while initializing a build for build definition \TFS\Build MAIN: The root element of the build process template found at $/TFS/BuildProcessTemplates/MainDefaultTemplate.xaml (version C182) is not valid. (The build process failed validation. Details: Validation Error: Compiler error(s) encountered processing expression "New Microsoft.TeamFoundation.Build.Workflow.Activities.BuildSettings()".'BuildSettings' is ambiguous in the namespace 'Microsoft.TeamFoundation.Build.Workflow.Activities'.

Rebuilding your custom assemblies against TFS 11 bits

Yes, that is our recommended solution to this problem. The build service, when loading your existing custom assemblies, will now look for the TFS 11 assemblies instead. Using the latest and greatest release is always a benefit in its own, so I hope you don’t think this is a big blocker. The Community TFS Build Extensions has already incorporated the custom assemblies built against TFS 11 in their most recent release.

Alternative?

If for any reason, you’d prefer not to recompile your custom assemblies, you can still redirect the build service process to load the version 11 by setting binding redirects for the referenced assemblies in the configuration file. When your custom activities need the version 10 assemblies, the CLR will be redirected to use version 11, and the WF services will live happily ever after.

Since we’ve maintained public APIs compatibility between releases, this approach should just work. You should be aware that this configuration will not let you load any other version of the redirected assemblies.

The change in TfsBuildServiceHost.exe.config will look similar to this:

 <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
 <dependentAssembly>
 <assemblyIdentity name="Microsoft.TeamFoundation.Build.Client" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
 <bindingRedirect oldVersion="10.0.0.0" newVersion="11.0.0.0"/>
 </dependentAssembly>
 <dependentAssembly>
 <assemblyIdentity name="Microsoft.TeamFoundation.Build.Workflow" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
 <bindingRedirect oldVersion="10.0.0.0" newVersion="11.0.0.0"/>
 </dependentAssembly>
</assemblyBinding>