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.
