TFS 2010 Custom Build Activity TF215097 error

问题:

For the Build Process in TFS 2010 I've created a library containing some custom code activities. In the past it all worked fine by adding the library (*.dll) to Source Control and setting the 'Build Controller - Version Control Path to Custom Assemblies' to the path where the library could be found in Source Control.

But since a few days (and I've been updating the library often) the build doesn't succeed anymore. The error reported is:

TF215097: An error occurred while initializing a build for build definition "Cannot create unknown type '{clr-namespace:BuildTasks;assembly=BuildTasks}'"

After searching I couldn't find any other solution than installing the library to the GAC. That works but I wonder why it is impossible to get it to work without having to install in to the GAC.

So although it working again now, I'd like to get it back to work the old way, without GAC. Hopefully some of you can help me. Thanks in advance.

回答1:

If you want to specify assemblies that contain custom code activities you've written you need to do the following:

1. Build you custom activities into your workflow.
2. Make sure your xmlns at the top is defined correctly: xmlns:local="clr-namespace:BuildTasks;assembly=BuildTasks"
3. Make sure the tags in the XAML for the build process have the local (or whatever prefix you've used) correctly.
4. Check in your updated workflow XAML into your team project and update your build definitions.
5. Create a new directory in your team project called "CustomBuildAssemblies"
6. Go to the bin/Debug (or release) folder of the project that you used to create the custom build tasks (basically get the dll that you're putting in the GAC) and place it into the directory created in step 5.
7. Tell the build controller where to look for the custom assemblies by going to Team Exporer, selecting the project you're doing this for, expand the project list out and right click on "Builds", and select "Manage Build Controllers". Sellect the controller (should be the first thing in the list) and click properties. Set the version control path to the directory that was created in step 5 (located in the middle of the popup).

At this point you have a custom XAML workflow that is referencing (importing) a custom assembly (or multiple ones) that have been included into source control. The build controller now knows where these custom assemblies are located. This allows you to "check in" new versions of those custom assemblies if you ever need to add/update your custom build tasks.

Hopefully this will help you out. It took me some time to figure this out as well. Let me know if I need to make this any more detailed. I wish I could post some screenshots of the dialogs.

UPDATE: I completely forgot about this thread till I saw that it was revived. I can also update this answer as I've found a very good way of making TFS pull the latest version of your custom build task assembly: Making a unique version number for the assembly.

I use a T4 template and run it before I build the assembly. It updates AssemblyInfo.cs after reading the checked-in custom activity DLL.

<#@ template debug="false" hostspecific="true" language="C#" #>
<#@ assembly name="System.Core" #>
<#@ assembly name="System.Xml.dll" #>
<#@ import namespace="System.Xml" #>
<#@ import namespace="System.Linq" #>
<#@ import namespace="System.Text" #>
<#@ import namespace="System.Collections.Generic" #>
<#@ import namespace="System.IO" #>
<#@ import namespace="System.Reflection" #>
<#@ output extension=".cs" #>
<#

 //relative path to the DLL for your custom assembly in source control
 var filename = this.Host.ResolvePath("..\\..\\..\\..\\BuildAssemblies\\BuildTasks.dll");

 Version buildInfoAssemblyVersion = AssemblyName.GetAssemblyName(filename).Version;

 // Setup the version information. Using the DateTime object make it kinda unique
 var version = new Version(DateTime.Now.Year, DateTime.Now.Month, DateTime.Now.Day, buildInfoAssemblyVersion.Revision + 1);

#>
using System.Reflection;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
using System.Windows.Markup;

// General Information about an assembly is controlled through the following 
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.
[assembly: AssemblyTitle("BuildTasks")]
[assembly: AssemblyDescription("")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("Microsoft")]
[assembly: AssemblyProduct("BuildTasks")]
[assembly: AssemblyCopyright("Copyright © Microsoft 2012")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]

// Setting ComVisible to false makes the types in this assembly not visible 
// to COM components.  If you need to access a type in this assembly from 
// COM, set the ComVisible attribute to true on that type.
[assembly: ComVisible(false)]

// The following GUID is for the ID of the typelib if this project is exposed to COM
[assembly: Guid("feab7e26-0830-4e8f-84c1-774268727cbd")]

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
// You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
// Version information is a combination of DateTime.Now and an incremented revision number coming from the file:
// <#= filename #>
[assembly: AssemblyVersion("<#= version.ToString() #>")]
[assembly: AssemblyFileVersion("<#= version.ToString() #>")]

[assembly: XmlnsDefinition("http://localhost/BuildTasks/Activities", "BuildTasks.Activities")]
[assembly: XmlnsDefinition("http://localhost/BuildTasks/Activities/InstallerA", "BuildTasks.Activities.InstallerA")]
[assembly: XmlnsDefinition("http://localhost/BuildTasks/Activities/InstallerB", "BuildTasks.Activities.InstallerB")]
[assembly: XmlnsDefinition("http://localhost/BuildTasks/Activities/CodeAnalysis", "BuildTasks.Activities.CodeAnalysis")]
[assembly: XmlnsDefinition("http://localhost/BuildTasks/Activities/Standards", "BuildTasks.Activities.Standards")]
[assembly: XmlnsDefinition("http://localhost/BuildTasks/Activities/CI", "BuildTasks.Activities.CI")]
[assembly: XmlnsDefinition("http://localhost/BuildTasks/Activities/Version", "BuildTasks.Activities.Version")]

You'll notice at the bottom I also setup XML namespace definitions for each of the namespaces that I use in the workflow. I've found that the generated XMAL looks much cleaner and it's also helped with my issues.

I created this file as AssemblyInfo.tt and just make sure I run it (right click and select run T4 or something like that) before building the assembly.

回答2:

This solution might not apply to all cases, as the answers provided in previous posts are correct, but were not the solution to my issue. This answer assumes the following:

1. the custom solution assemblies are all changed in checked in and are correctly tagged and built.
2. The build controller has been pointed at the correct source control location for the custom assemblies.

What I and(I suspect many others) are doing is copying, or linking their xaml workflow documents into the solution so you can use the workflow designer and the new custom assemblies. Well, this works great in the VS designer, but VS will modify your assembly references with its own. For example I have a reference that looks like the following:

xmlns:ca="clr-namespace:Custom.TFS.Activities;assembly=Custom.TFS.Activities" 

After editing the workflow with my project solution, visual studio changed that to:

xmlns:local="clr-namespace:Custom.TFS.Activities" 

When you check this file in to test or use, you will now see the dreaded TF215097 error.

Adding the ;assembly=your.assembly should fix the problem and remove the need to put everything in the GAC. You might also need to fix the name space references using in the rest of the xaml file.

BIG THANKS TO: http://msmvps.com/blogs/rfennell/archive/2010/03/08/lessons-learnt-building-a-custom-activity-to-run-typemock-isolator-in-vs2010-team-build.aspx

回答3:

You need this attribute on your codeActivity class:

<BuildActivity(HostEnvironmentOption.All)> _

Elsewhere, the assembly is not loaded.

回答4:

As mentioned by Rhapsody on June 2 2010, the GAC can be used. However it needs to be noted that if you do use the GAC, you need to stop and restart the build service, so that it re-scans the GAC, hence picking up your DLL.

I had initially registered my DLL in the GAC, and when I kicked off a build that pointed to a workflow consisting of my custom code activity assembly, the build failed. But after stopping and restarting the build service, the build does not fail straight away with the dreaded "An error occurred while initializing a build for build definition [BuildDefinitionName] : Cannot create unknown type...".

回答5:

This worked for me -- the assembly name needs to be included in the namespace declaration for the custom control:

http://blogs.microsoft.co.il/blogs/royrose/archive/2010/06/09/custom-build-activities-and-tf215097-error.aspx

回答6:

I didn't find an answer to this problem up today, so probably this answer will arrive too late for some of you.

I was really stuck trying to do the same from GAC, modifying namespace declaration and i always was finding the famous "Cannot create unknown type '{clr-namespace:bla,bla,bla". Modifying all build templates each time you can add a new assembly is a painful and annoying experience. I've experienced some issues by setting assembly in GAC, it looks like there is some kind of cache because custom activities were not refreshed even if i uninstalled and reinstalled assembly from GAC,

Finally, I found in http://msdn.microsoft.com/en-us/library/ee330987.aspx that you can add custom assemblies with custom activities by adding them to Source Control and setting control path for custom assemblies in Build Controller Properties (you can access from Team Foundation Administration Console --> Build Configuration --> Controller Properties)

You Just need to add your assemblies to source control and TFS will take care about everything.

share|improve this answer