Erreur TF215097 de l'activité de construction personnalisée TFS 2010

Pour le Processus de génération dans TFS 2010, j'ai créé une bibliothèque contenant le code personnalisé d'activités.
Dans le passé, tout a bien fonctionné par l'ajout de la bibliothèque (*.dll) à la Source de Contrôle et de réglage de la "Contrôleur de Build de la Version de Contrôle de Chemin à des Assemblys Personnalisés" pour le chemin d'accès où la bibliothèque a pu être trouvé dans le Contrôle de Source.

Mais depuis quelques jours (et j'ai eu la mise à jour de la bibliothèque souvent) la compilation ne marche pas plus.
L'erreur signalée est:

TF215097: Une erreur s'est produite lors
l'initialisation d'un build pour construire
définition de "Ne peut pas créer inconnu
le type " {clr-namespace:BuildTasks;assembly=BuildTasks}'"

Après la recherche je ne pouvais pas trouver d'autre solution que de l'installation de la bibliothèque à la GAC. Qui fonctionne mais je me demande pourquoi il est impossible de le faire fonctionner sans avoir à installer dans le GAC.

Si bien qu'il fonctionne à nouveau maintenant, j'aimerais me remettre au travail à l'ancienne, sans GAC. J'espère que certains d'entre vous peut m'aider. Merci à l'avance.

source d'informationauteur Rhapsody | 2010-05-26

Si vous souhaitez spécifier des assemblages qui contiennent le code personnalisé à des activités que vous avez écrit, vous devez effectuer les opérations suivantes:

Vous créer des activités personnalisées en
votre flux de travail.
Assurez-vous que votre
xmlns au sommet est défini
correctement:
xmlns:local="clr-namespace:BuildTasks;assembly=BuildTasks"
Assurez-vous que les balises dans le code XAML pour
le processus de construction ont le local (ou
le préfixe que vous avez utilisé)
correctement.
Vérifier dans la mise à jour de votre XAML de flux de travail dans votre équipe projet et de mettre à jour vos définitions de build.
Créer un nouveau répertoire dans votre équipe projet appelé "CustomBuildAssemblies"
Aller à la bin/Debug (ou libération) dossier du projet que vous avez utilisé pour créer le custom build tâches (essentiellement obtenir la dll que vous mettez dans le GAC) et le placer dans le répertoire créé à l'étape 5.
Dire le contrôleur de build où chercher pour les assemblys personnalisés en allant à l'Équipe de Exporer, en sélectionnant le projet que vous êtes en train de faire ce pour, développez le projet de liste de droite et cliquez sur "Construit", et sélectionnez "Gérer les Contrôleurs de Construire". Sellect le contrôleur (qui devrait être la première chose dans la liste), puis cliquez sur propriétés. Définir le contrôle de version chemin vers le répertoire qui a été créé à l'étape 5 (situé dans le milieu de la fenêtre contextuelle).

À ce stade, vous avez une coutume de flux de travail XAML qui est de référencement (importer) un assembly personnalisé (ou plusieurs) qui ont été inclus dans le contrôle de source. Le contrôleur de build sait maintenant où ces assemblys personnalisés sont situés. Cela vous permet de vérifier les nouvelles versions de ces assemblys personnalisés si vous avez besoin d'ajouter/mettre à jour votre version personnalisée tâches.

J'espère que cela va vous aider. Il m'a fallu un certain temps pour comprendre cela. Permettez-moi de savoir si j'ai besoin de faire cela une fois de plus détaillé. Je souhaite que je pourrais poster quelques captures d'écran de la boîte de dialogue.

Mise à JOUR:
J'ai complètement oublié ce thread jusqu'à ce que je voyais qu'il a été relancé. Je peux également mettre à jour cette réponse que j'ai trouvé une très bonne façon de faire de la TSF tirer la dernière version de votre version personnalisée de la tâche de l'assemblée: la création d'un numéro de version unique pour l'assemblée.

- Je utiliser un modèle T4 et de l'exécuter avant de me construire l'assemblée. Il met à jour AssemblyInfo.cs après la lecture de l'extrait en activité personnalisée 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")]

Vous remarquerez en bas j'ai aussi l'installation d'espace de noms XML définitions pour chacun des espaces de noms que j'utilise dans le flux de travail. J'ai trouvé que le XMAL a l'air beaucoup plus propre et c'est aussi aidé avec mes questions.

J'ai créé ce fichier AssemblyInfo.tt et assurez-vous simplement que je le lance (clic droit et sélectionnez exécuter en T4 ou quelque chose comme ça) avant de construire l'assemblée.

8

Cette solution peut ne pas s'appliquer à tous les cas, les réponses fournies dans les messages précédents sont corrects, mais n'étaient pas la solution à mon problème. Cette réponse repose sur les hypothèses suivantes:
1. la solution personnalisée assemblées sont tout a changé dans vérifiés et sont correctement identifiés et intégrés.
2. Le contrôleur de build a été pointé à la bonne source, l'emplacement de contrôle pour les assemblys personnalisés.
Ce que j'ai et(je soupçonne que beaucoup d'autres) sont en train de faire est de copier ou de les relier leurs xaml documents de flux de travail dans la solution de sorte que vous pouvez utiliser le concepteur de flux de travail et la nouvelle assemblys personnalisés. Eh bien, cela fonctionne très bien dans le VS designer, mais contre la volonté de modifier vos références d'assembly avec son propre. Par exemple, j'ai une référence qui se présente comme suit:
```
xmlns:ca="clr-namespace:Custom.TFS.Activities;assembly=Custom.TFS.Activities" 
```
Après l'édition de ce flux à mon projet de solution de visual studio changé:
```
xmlns:local="clr-namespace:Custom.TFS.Activities" 
```
Quand vous cliquez sur ce fichier pour tester ou utiliser, vous allez maintenant voir le redoutable TF215097 erreur.

L'ajout de la ;assembly=your.assembly devrait résoudre le problème et de supprimer la nécessité de tout mettre dans le GAC. Vous pourriez aussi avoir besoin de corriger le nom de l'espace à l'aide de références dans le reste du fichier xaml.

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

Vous avez besoin de cet attribut sur votre codeActivity classe:

<BuildActivity(HostEnvironmentOption.Tous)> _

Ailleurs, l'assemblée n'est pas chargé.
2

Comme mentionné par Rhapsody le 2 juin 2010, le GAC peut être utilisé. Toutefois, il convient de noter que si vous utilisez le GAC, vous devez arrêter et redémarrer le service, de sorte qu'il re-scanne le GAC, donc ramasser votre DLL.

J'avais d'abord enregistré ma DLL dans le GAC, et quand j'ai démarré une génération qui a fait à un flux de travail composé de mon code personnalisé de l'activité de l'assemblée, la compilation a échoué. Mais après l'arrêt et le redémarrage du service de build, l'accumulation de ne pas tout de suite avec le redoutable "Une erreur s'est produite lors de l'initialisation d'un build pour construire définition [BuildDefinitionName] : Impossible de créer le type inconnu...".
1

Cela a fonctionné pour moi -- le nom de l'assemblage doit être inclus dans la déclaration d'espace de noms pour le contrôle personnalisé:

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

Je n'ai pas trouver de réponse à ce problème jusqu'à aujourd'hui, et c'est probablement cette réponse arrive trop tard pour certains d'entre vous.

J'étais vraiment coincé à essayer de faire de même à partir de GAC a, à la modification de déclaration d'espace de noms et je me suis toujours a la recherche du fameux "Impossible de créer le type inconnu '{clr-namespace:bla,bla,bla". La modification de tous les de construire des modèles à chaque fois, vous pouvez ajouter une nouvelle assemblée est d'un pénible et ennuyeux de l'expérience. J'ai connu quelques problèmes en définissant l'assembly dans le GAC, il semble qu'il y est une sorte de cache, car la coutume activités n'ont pas été actualisées, même si je l'ai désinstallé et réinstallé assemblée à partir de GAC,

Enfin, j'ai trouvé dans http://msdn.microsoft.com/en-us/library/ee330987.aspx que vous pouvez ajouter des assemblages avec des activités personnalisées en les ajoutant à la Source de Contrôle et de réglage de chemin de contrôle pour les assemblys personnalisés en Construire Propriétés du Contrôleur (vous pouvez accéder à partir de l'Équipe de la Fondation de la Console d'Administration --> Configuration de Build --> Propriétés du Contrôleur)

Vous suffit d'ajouter vos assemblées à la source de contrôle et TFS prendra soin de tout.
1

J'ai eu exactement ce même problème. La raison était que j'avais compilé la bibliothèque avec la coutume des activités de lutte contre la plate-forme x86 et le Contrôleur de Build a été en cours d'exécution hors de la version 64 bits de Windows 2008 VM. La commutation de la plate-forme cible pour AnyCPU a permis de constituer contrôleur immédiatement d'utiliser la bibliothèque sans avoir à ajouter le GAC.
1

Le correctif avais-je besoin pour créer une définition de classe partielle de ma classe, et d'appliquer les BuildActivity attribut. Mon problème est que j'ai été absent de la BuildActivity l'attribut de ma classe d'activité, depuis que j'ai eu il mis en œuvre dans Xaml libre et non pas comme un Code d'Activité, donc ce fixe pour moi.

Soi-disant, l'Équipe de Construire des charges de tout assemblage contenant une classe avec BuildActivity ou BuildExtension sur elle, et en théorie, cela devrait se traduire dans toutes les classes de ladite assemblée, étant disponibles à la construction. Cela aurait permis une sorte de mannequin chargeur de classe qui permettrait de chargement des activités Xaml sans avoir besoin de ces partielle des définitions de classe, mais dans la pratique cela ne fonctionne pas pour moi.
1

Windows, vérifiez les notifications d'Événements. Votre activité personnalisée DLL peut-être PAS obtenu chargé correctement.

Si elle n'a pas, alors vous pouvez avoir à changer la plate-forme cible de votre activité personnalisée projet... soit 32 bits ou 64 bits.
0

Depuis aucune réponse n'est donnée, et je n'ai pas trouvé de correctif, j'ai décidé de mettre dans le GAC maintenant.
Qui fonctionne aussi bien. 🙂
0

L'Attribut mentionné ci-dessus est:
```
Microsoft.TeamFoundation.Build.Client.BuildActivity( Microsoft.TeamFoundation.Build.Client.HostEnvironmentOption.Agent )
```
En général, il semble vraiment comme TF215097 peut signifier "vous êtes stuff est cassé", pas juste "je ne pouvais pas le trouver".
0

Une autre source de cette erreur si vous avez par erreur mélange de construire des extensions pour les différentes versions de TFS. Par exemple, si vous êtes d'utilisation de TFS 2012, mais essayez d'utiliser TFS 2013 construire des extensionsvous obtiendrez cette erreur.
0

Je n'ai pas de succès avec les autres réponses dans ce fil, cependant, je pensais que je voudrais partager ce que j'ai fait. Mon assembly personnalisé a été chargé sur ma machine de compilation par le GAC. J'ai dû ouvrir manuellement le modèle de génération du fichier XAML et d'ajouter ma assemblée à l'espace de noms de référence. Pour une raison que Visual Studio n'a pas été correctement référencement de cela pour moi.

Avant:
```
xmlns:ba1="clr-namespace:BuildTasks.Activities"
```
Après
```
xmlns:ba1="clr-namespace:BuildTasks.Activities;assembly=ModifyTasks"
```
Ma version personnalisée de la tâche de l'assemblée est appelée ModifyTasks.dll le remplacer par votre propre nom de fichier...
0

J'ai rencontré le même problème après un redémarrage de notre TFS 2012 serveur de build. De l'IC de l'emploi qui a été exécuté parfaitement bien arrêté de travailler avec le mentionné TF215097 erreur, il a été incapable de trouver une activité personnalisée.

Un commentaire sur cette 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) a suggéré de supprimer l'ensemble de la source chemin de la coutume de l'activité des Dll dans le contrôleur de build configuration, l'enregistrement de la configuration mise à jour, re-ajouter le même chemin d'accès et l'enregistrement de nouveau.

Cela a réglé le problème pour moi.

Vous devez vous connecter pour publier un commentaire.