Your custom assemblies need update, or else, redirecting

  • Article

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>

Comments

  • Anonymous
    June 07, 2012
    where do i find this  TfsBuildServiceHost.exe.config ?

  • Anonymous
    March 19, 2013
    Thanks for the workaround! In addition to Build.Client and Build.Workflow, I needed to add a binding redirect for VersionControl.Client as well: <dependentAssembly>    <assemblyIdentity name="Microsoft.TeamFoundation.VersionControl.Client" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>    <bindingRedirect oldVersion="10.0.0.0" newVersion="11.0.0.0"/> </dependentAssembly> This enabled us to open build workflow (XAML) files in 2012 that target .NET 4.0 and WF 4.0, as well as custom activities referencing the 10.0.0.0 TeamFoundation.* assemblies.

  • Anonymous
    May 07, 2013
    Is this still true for TFS Update 2? I'm getting errors relating to loading types from Microsoft.TeamFoundation.Build.Workflow.dll.

  • Anonymous
    May 11, 2013
    We are getting the following error when trying to run our TFS Builds from an upgraded TFS 2010 server to TFS 2012.3 RC. specified argument was out of the range of valid values. Parameter name: column. We are using our TFS 2010, yes 2010, Build Controller and 2010 Build agents (installed on SRV 2003 so can't install 2012) against our newly upgrade TFS 2012.3 RC server. Again we have upgraded to 2012.3 RC and are trying to use the build backward compatibility was released with TFS 2012.2 (update 2)  Here is a screen shot: http://i.imgur.com/Ze1bpPQ.png