© DrHitch/Shutterstock.com
TFS 2012 Team Build

5 Eigene Workflow Activities entwickeln


Wenn Anpassungen am Workflow nicht mehr ausreichend sind, um die gestellten Anforderungen zu erfüllen, ist die nächste Stufe gefragt: die Entwicklung eigener Aktivitäten.

5.1 Projektstruktur und Referenzen

Es wird eine Solution mit zwei Projekten benötigt. Das erste Projekt ist eine normale Klassenbibliothek, die den eigentlichen Code der eigenen Activities enthält. Das zweite Projekt ist ein Projekt vom Typ Workflow | Activity Library. Dieses Projekt hat eine Referenz auf das Activity-Projekt und enthält die angepasste Version des Build-Workflows, der die eigenen Aktivitäten verwendet. Den Workflow kopiert man aus dem Ordner $/Lab/BuildProcessTemplates in das Projektverzeichnis und fügt die .xaml-Datei dem Projekt hinzu. Die Projektstruktur ist in Abbildung 5.1 dargestellt.

5_1_EigeneActivities-Projektstruktur.png

Abbildung 5.1: Die Projektstruktur für Workflows mit eigenen Activities

Die Klassenbibliothek benötigt zunächst einen Verweis auf die System.Activities.dll, da diese die Basisklasse für eigene Aktivitäten, System.Activities.CodeActivity, enthält. Speziell für Aktivitäten, die im Build-Umfeld genutzt werden sollen, ist die Einbindung der Microsoft.TeamFounation.Build.Workflow.dll erforderlich. Diese beinhaltet einige hilfreiche Erweiterungsmethoden. Welche Referenzen darüber hinaus noch benötigt werden, hängt damit zusammen, was die Aktivität leisten soll. Pauschal lohnt es sich meistens, noch über die Microsoft.TeamFoundation.Build.Client.dll und die Microsoft.TeamFoundation.VersionControl.Client.dll nachzudenken, da diese für viele Dinge rund um den TFS benötigt werden. Alle benötigten Referenzen sind in Tabelle 5.1 zusammengestellt.

Das Workflow-Projekt benötigt eine ganze Menge an Referenzen. Diese sind allesamt durch den Build Workflow, der ja Teil des Projekts ist, begründet, der sich aus vielen Töpfen bedient. Es wäre müßig, der Bedeutung jeder Referenz nachzugehen – erst wenn alle Referenzen da sind, ist der Compiler zufrieden und kompiliert das Projekt. Also Augen zu und durch – Tabelle 5.1 enthält alles, was man braucht. Die beiden letzten Assemblies nehmen eine Sonderstellung ein, da sie nicht einfach aus dem Referenz hinzufügen-Dialog aufgenommen werden können, sondern per Durchsuchen. Der Quellordner ist als Bemerkung angegeben.

Referenz

Beschreibung

Refrenzen für das Activity-Projekt

System.Activities

Enthält die Basisklasse für jegliche Aktivitäten

Microsoft.TeamFoundation.Build.Workflow

Enthält Ergänzungen speziell für Aktivitäten, die in Build Workflows genutzt werden sollen

Microsoft.TeamFoundation.Build.Client

Enthält clientseitige API-Klassen für Team Build

Microsoft.TeamFoundation.VersionControl.Client

Enthält clientseitige API-Klassen für die Versionskontrolle – wird häufig im Zusammenhang mit Team-Build-Aktivitäten benötigt

Referenzen für das Workflow-Projekt

Microsoft.TeamFoundation

Notwendig für die Build-Aktivitäten im Workflow

Microsoft.TeamFoundation.Common

Microsoft.TeamFoundation.Build.Client

Microsoft.TeamFoundation.Build.Workflow

Microsoft.TeamFoundation.VersionControl.Client

Microsoft.TeamFoundation.VersionControl.Common

Microsoft.TeamFoundation.WorkItemTracking.Client

System.Drawing

Notwendig für die Darstellung des Workflows

System.Activities.Presentation

Presentation Framework

Windows Base

Microsoft.TeamFoundation.TestImpact.
BuildIntegration

Quelle: C:\Program Files\Microsoft Team Foundation Server 11.0\Tools

Microsoft.TeamFoundation.TestImpact.Client

Quelle: C:\Windows\assembly\GAC_MSIL\Microsoft.TeamFoundation.TestImpact.Client\11.0.0.0__b03f5f7f11d50a3a

Tabelle 5.1: Notwendige und hilfreiche Verweise für eigene Aktivitäten

Nicht zu vergessen natürlich die Referenz auf die Klassenbibliothek mit den eigenen Aktivitäten. Beide Projekte gehören natürlich in die Versionskontrolle. Wichtig ist dies besonders für das Workflow-Projekt, da die Build-Definitionen die Prozessvorlage über den Versionskontrollpfad finden. Neben der .xaml-Datei für den Workflow muss auch die Assembly mit den eigenen Aktivitäten in die Versionskontrolle, da man später dem Build Controller beibringen muss, wo er sie finden kann. Auch er möchte dazu gerne einen Versionskontrollpfad. Am einfachsten ist es, die .dll in das gleiche Projekt wie den Workflow zu packen.

Profitipp: Die oben genannten Verweise werden nur benötigt, wenn das Workflow Template in dem Projekt die Build Action XamlAppDef aufweist und als Custom Tool MSBuild:Compile. In diesem Fall wird die Xaml-Datei kompiliert und auf Fehler überprüft. Wenn Sie auf diese Überprüfung verzichten wollen, stellen Sie die Build Action auf None und löschen den Eintrag bei Custom Tool. In diesem Fall geschieht keine Kompilierung des Workflows, wenn das Projekt kompiliert wird, und die Verweise im Workflow-Projekt können entfallen.

5.2 Hello World

Nachdem die Projektstruktur steht, kann man mit der Implementierung einer ersten Aktivität beginnen. Wie der Programmiererethos es verlangt, wird das eine Hello-World-Aktivität, die „Hello World“ im Build Log ausgeben soll. Ein Codegerüst für eigene Aktivities ist recht einfach, wie in Listing 5.1 zu sehen:

[BuildActivity(HostEnvironmentOption.Agent)]
public sealed class HelloWorld : CodeActivity
{
protected override void Execute(CodeActivityContext context)
{
}
}

Listing 5.1: Codegerüst für eigene Aktivitäten

Man leitet von der Klasse System.Activities....

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang