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 开发者_StackOverflow社区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.

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.

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

You need this attribute on your codeActivity class:

<BuildActivity(HostEnvironmentOption.All)> _

Elsewhere, the assembly is not loaded.

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...".

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

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.

I had this exact same problem. The reason was that I had compiled the library with the custom activities against the x86 platform and the Build Controller was running off of a 64-bit Windows 2008 VM. Switching the target platform to AnyCPU allowed the build controller to immediately utilize the library without having to add it to the GAC.

The fix I needed was to create a partial class definition of my class, and apply the BuildActivity attribute to it. My problem was that I was missing the BuildActivity attribute on my activity class, since I had implemented it in loose Xaml and not as a Code Activity, so this fixed it for me.

Supposedly, Team Build loads up any assembly containing a class with BuildActivity or BuildExtension on it, and in theory this should result in any class in said assembly being available to the build. This would have enabled a kind of dummy loader class that would allow loading of Xaml activities without needing these partial class definitions, but in practice that didn't work for me.

Check your Windows Event notifications. Your custom activity DLL may NOT have gotten loaded properly.

If it did not, then you may have to change the platform target of your custom activity project... either to 32bit or 64 bit.

Since no answer is given and I haven't found any fix, I decided to put in the GAC now. That works as well. :)

The Attribute mentioned above is:

Microsoft.TeamFoundation.Build.Client.BuildActivity( Microsoft.TeamFoundation.Build.Client.HostEnvironmentOption.Agent )

In general, it really seems like TF215097 can mean "you're stuff is broken" not just "I couldn't find it".

Another source of this error if you by mistake mix build extensions for different versions of TFS. For instance if you are using TFS 2012 but try to use TFS 2013 build extensions you will get this error.

I didn't have any success with the other answers in this thread however I thought I'd share what I did. My custom assembly was loaded onto my build machine through GAC. I had to manually open the build template XAML file and add my assembly to the namespace reference. For some reason Visual Studio wasn't properly referencing this for me.

Before:

xmlns:ba1="clr-namespace:BuildTasks.Activities"

After

xmlns:ba1="clr-namespace:BuildTasks.Activities;assembly=ModifyTasks"

My custom build task assembly is called ModifyTasks.dll replace it with your own file name...

I encountered the same issue after a reboot of our TFS 2012 build server. A CI job that was running perfectly fine stopped working with the mentioned TF215097 error, it was unable to find a custom activity.

A comment on this page (https://social.msdn.microsoft.com/Forums/vstudio/en-US/479449e1-5c02-4744-b620-3bba64038cef/custom-build-activity-tf215097-cannot-create-unknown-type?forum=tfsbuild) suggested removing the set source path to the custom activity DLLs in the build controller configuration, saving the updated configuration, re-adding the same path and saving again.

This fixed the issue for me.