When embracing Team
Build 2010, you typically want to define several different
build process templates for different scenarios. Common examples here are CI builds, QA builds and release builds. For example, in a contiuous
build you often have no interest in publishing to the symbol store, you might or might not want to associate changesets and work items etc. The
build server is often heavily occupied as it is, so you don’t want to have it doing more that necessary. Try to define a set of
build process templates that are used across your company. In previous versions of TFS Team
Build, there was no easy way to do this. But in TFS 2010 it is very easy so there is no excuse to not do it! :-)
I ran into a scenario today where I had an existing
build definition that was based on our release
build process template. In this template, we have defined several different
build process parameters that control the release
build. These are placed into its own sectionin the
Build Process Parameters editor. This is done using the ProcessParameterMetadataCollection element, I will explain how this works in a future post.
I won’t go into details on these parametes, the issue for this blog post is what happens when you modify a
build process template so that it is no longer compatible with the
build definition, i.e. a breaking change. In this case, I removed a parameter that was no longer necessary. After merging the new
build process template to one of the projects and queued a new release
build, I got this error:
TF215097: An error occurred while initializing a
build for
build definition <Build Definition Name>:
The values provided for the root activity's arguments did not satisfy the root activity's requirements: 'DynamicActivity':
The following keys from the input dictionary do not map to arguments and must be removed: <Parameter Name>.
Please note that argument names are case sensitive. Parameter name: rootArgumentValues
<Parameter Name> was the parameter that I removed so it was pretty easy to understand why the error had occurred. However, it is not entirely obvious how to fix the problem. When open the
build definition everything looks OK, the removed
build process parameter is not there, and I can open the
build process template without any validation warnings.
The problem here is that all settings specific to a particular
build definition is stored in the TFS database. In TFS 2005, everything that was related to a
build was stored in TFS source control in files (TFSBuild.proj, WorkspaceMapping.xml..). In TFS 2008, many of these settings were moved into the database. Still, lots of things were stored in TFSBuild.proj, such as the solution and configuration to
build, wether to execute tests or not. In TFS 2010, all settings for a
build definition is stored in the database. If we look inside the database we can see what this looks like. The table tbl_BuildDefinition contains all information for a
build definition. One of the columns is called ProcessParameters and contains a serialized representation of a Dictionary that is the underlying object where these settings are stoded. Here is an example:
<Dictionary x:TypeArguments="x:String, x:Object" xmlns="clr-namespace:System.Collections.Generic;assembly=mscorlib" xmlns:mtbwa="clr-namespace:Microsoft.TeamFoundation.
Build.Workflow.Activities;assembly=Microsoft.TeamFoundation.
Build.Workflow" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<mtbwa:BuildSettings x:Key="BuildSettings" ProjectsToBuild="$/PathToProject.sln">
<mtbwa:BuildSettings.PlatformConfigurations>
<mtbwa:PlatformConfigurationList Capacity="4">
<mtbwa:PlatformConfiguration Configuration="Release" Platform="Any CPU" />
</mtbwa:PlatformConfigurationList>
</mtbwa:BuildSettings.PlatformConfigurations>
</mtbwa:BuildSettings>
<mtbwa:AgentSettings x:Key="AgentSettings" Tags="Agent1" />
<x:Boolean x:Key="DisableTests">True</x:Boolean>
<x:String x:Key="ReleaseRepositorySolution">ERP</x:String>
<x:Int32 x:Key="Major">2</x:Int32>
<x:Int32 x:Key="Minor">3</x:Int32>
</Dictionary>
Here we can see that it is really only the non-default values that are persisted into the databasen. So, the problem in my case was that I removed one of the parameteres from the
build process template, but the parameter and its value still existed in the
build definition database. The solution to the problem is to refresh the
build definition and save it. In the process tab, there is a Refresh button that will reload the
build definition and the process template and synchronize them:
After refreshing the
build definition and saving it, the
build was running successfully again.
