Use Legacy Build Processes
When you upgrade from earlier versions of Team Foundation Server, you can continue to use legacy build processes. You can also continue to use older versions of Visual Studio to create build processes on Visual Studio Team Foundation Server 2012.
What do you want to do?
Run a legacy build process on a server that has been upgraded to Visual Studio Team Foundation Server 2012
Run a build process based on a custom template that you created or edited using Visual Studio 2010
Run a build process that leverages custom activities
Create and use a build process using Visual Studio 2010
Create and use a build process created with Visual Studio 2008
See also: Upgrading your build definitions from TFS2010 to TFS2012 (by Jason Pricket).
Run a legacy build process on a server that has been upgraded to Visual Studio Team Foundation Server 2012
After you upgrade to Visual Studio Team Foundation Server 2012, you can continue to use build processes that are based on DefaultTemplate.xaml and UpgradeTemplate.xaml.
Tip
You can continue to use build definitions (and even create new ones) that are based on DefaultTemplate.xaml, but in many cases, you will obtain better results by using DefaultTemplate.11.1.xaml.
In a few situations, you must take some actions to enable your legacy build process to function correctly on Visual Studio Team Foundation Server 2012:
Run a build process based on a custom template
You must use only Visual Studio 2012 to edit your build process templates. If a build process template has been edited using Visual Studio 2010, you must edit the build process template using a text editor and remove all strong name references to Microsoft.TeamFoundation namespaces from the Activity element.
For example, you must remove lines such as:
xmlns:mtvc="clr-namespace:Microsoft.TeamFoundation.VersionControl.Client;assembly=Microsoft.TeamFoundation.VersionControl.Client, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
and leave in lines such as
xmlns:mtvc1="clr-namespace:Microsoft.TeamFoundation.VersionControl.Client;assembly=Microsoft.TeamFoundation.VersionControl.Client"
Otherwise, you might receive a message such as Error 7 Compiler error(s) encountered processing expression "Workspace". Value of type 'Microsoft.TeamFoundation.VersionControl.Client.Workspace' cannot be converted to 'Microsoft.TeamFoundation.VersionControl.Client.Workspace'. Type mismatch could be due to…
Tip
Jason Pricket published some source code to automatically clean these issues out of your build process template. See TFS 2012 – Cleaning up Workflow XAML files (AKA removing versioned namespaces)
Run a build process that leverages custom activities
Before you can run a build process that leverages custom build process activities, you must first recompile the activities with the .NET Framework 4.5 (for example, using Visual Studio 2012 or Team Foundation Build 2012) and then check them in to the version control folder referenced by your build controller. If you try to run a build process that leverages custom build activities compiled with an earlier version of the .NET Framework, you might see the following message in the build results log: “Set property 'Microsoft.TeamFoundation.Build.Workflow.Activities.SyncWorkspace.RequestsFailed' threw an exception.”
Create and run a build process using Visual Studio 2010
When you use Visual Studio 2010 to create a build process on Visual Studio Team Foundation Server 2012, you can create a build process based on DefaultTemplate.11.1.xaml.
Create and run a build process created with Visual Studio 2008
You can continue to use build definitions that were created using Visual Studio 2008. When you first upgrade to Visual Studio Team Foundation Server 2012, the system automatically creates a build definition that is based on UpgradeTemplate.xaml for each legacy build definition and each build type that is in your deployment.
You can also use Visual Studio 2008 to create new build definitions on Visual Studio Team Foundation Server 2012. In both cases, the server automatically wraps the functionality in a build process that is based on UpgradeTemplate.xaml.