Freigeben über

Team Foundation Build-Aktivitäten

  • Artikel

Die Team Foundation Build-Aktivitäten sind die zentralen Komponenten des Buildprozesses im Team Foundation Build-System. Sie können mit diesen Aktivitäten einen benutzerdefinierten Buildprozess erstellen, z. B. um spezifischen Teamanforderungen gerecht zu werden. Dazu gehört z. B. (wie im nachfolgenden Beispiel) das Erstellen einer benutzerdefinierten Logik oder die Ausführung spezieller Aufgaben.

In den meisten Fällen sollten Sie die benutzerdefinierte Buildprozessvorlage auf der Grundlage der Standardvorlage (DefaultTemplate.xaml) erstellen. Auf diese Weise können Sie auf bereits vorhandene allgemeine Funktionen zugreifen und einzelne Abschnitte gezielt Ihren Anforderungen anpassen. Ein weiterer Vorteil dieses Ansatzes besteht darin, dass Ihnen praktische Beispiele für die Verwendung der in diesem Thema beschriebenen Aktivitäten zur Verfügung stehen. Weitere Informationen zum Erstellen einer Buildprozessvorlage finden Sie unter Erstellen und Verwenden einer benutzerdefinierten Buildprozessvorlage.

Wichtig

Sie sollten einen benutzerdefinierten Buildprozess nur erstellen, wenn Sie besondere Anforderungen erfüllen müssen. Sie können mit DefaultTemplate.xaml schnell einen Buildprozess definieren, der viele typische Anforderungen erfüllt. Weitere Informationen finden Sie unter Definieren eines Builds mithilfe der Standardvorlage.

In diesem Thema

  • Erforderliche Berechtigungen

  • Verweis auf Aktivitäten (geordnet nach Zielsetzung)

  • Verweis auf Aktivitäten (in alphabetischer Reihenfolge)

Erforderliche Berechtigungen

Um Prozeduren auszuführen, die Team Foundation Build-Aktivitäten verwenden, müssen die Berechtigungen für folgende Aktionen auf Zulassen festgelegt sein:

  • Builddefinition bearbeiten

  • Auschecken und Einchecken für die relevanten Versionskontrollverzeichnisse (z. B. das BuildProcessTemplates-Unterverzeichnis des Teamprojekts)

  • Hinzufügen von Builds zur Warteschlange

Weitere Informationen finden Sie unter Team Foundation Server-Berechtigungen.

Verweis auf Aktivitäten (geordnet nach Zielsetzung)

  • Ausführen grundlegender Aufgaben

    • Abrufen der Werte von Umgebungsvariablen

    • Abrufen von Pfaden zu Dateien im Arbeitsbereich

    • Arbeiten mit Verzeichnissen

    • Abrufen des Pfads zum Build-Agent-Arbeitsverzeichnis

    • Herunterladen von Dateien, die sich nicht in einem Arbeitsbereich befinden

    • Suchen von Dateien

    • Schreiben von Warnungen, Fehlern, Meldungen und anderen Daten in das Buildprotokoll

    • Schreiben von Build-Metadaten in das Data Warehouse

  • Steuern des Buildprozesses

    • Ausführen von Build-Agent-Aktivitäten

    • Verwenden einer benannten Mutex-Struktur, um einen threadsicheren Prozess zu implementieren

    • Einschränken bestimmter Abschnitte des Buildprozesses nach der Ursache (Trigger)

  • Kompilieren, Testen und Ausführen weiterer Aufgaben

    • Verwenden von MSBuild, um Binärdateien zu kompilieren, Codeanalysen und weitere Aufgaben auszuführen

    • Verwenden von MSTest zur Durchführung von Tests

    • Abrufen einer Liste der Tests, die von einem Build betroffen sind

    • Starten eines Prozesses

  • Arbeiten mit der Versionskontrolle

    • Verknüpfen von Changesets und Arbeitsaufgaben mit dem Build

    • Einchecken abgegrenzter Änderungen

    • Prüfen von Eincheckrichtlinien

    • Bezeichnen von Dateien in der Versionskontrolle

  • Arbeiten mit Arbeitsaufgaben

    • Verknüpfen von Changesets und Arbeitsaufgaben mit dem Build

    • Arbeitsaufgabe erstellen

  • Arbeiten mit Symboldaten

    • Einbetten von Versionskontrollpfaden und Versionen in die Symboldaten der PDB-Dateien

    • Veröffentlichen von Symbolen in einem SymStore-Symbolspeicher

  • Abrufen von Verweisen auf nützliche Objekte

    • Abrufen eines Verweises auf ein Objekt für eine Teamprojektsammlung

    • Abrufen eines Verweises auf ein Objekt für einen Build-Agent

    • Abrufen eines Verweises auf ein Objekt für ein Builddetail

    • Abrufen eines Verweises auf ein Objekt für eine Buildumgebung

Verweis auf Aktivitäten (in alphabetischer Reihenfolge)

  • AgentScope

  • AssociateChangesetsAndWorkItems

  • CheckInGatedChanges

  • ConvertWorkspaceItem

  • ConvertWorkspaceItems

  • CopyDirectory

  • CreateDirectory

  • CreateWorkspace

  • DeleteDirectory

  • DeleteWorkspace

  • DownloadFile

  • DownloadFiles

  • EvaluateCheckInPolicies

  • ExpandEnvironmentVariables

  • FindMatchingFiles

  • GetBuildAgent

  • GetBuildDetail

  • GetBuildDirectory

  • GetBuildEnvironment

  • GetImpactedTests

  • GetTeamProjectCollection

  • GetWorkspace

  • IndexSources

  • InvokeForReason

  • InvokeProcess

  • LabelSources

  • LabelWorkspace

  • MSBuild

  • MSTest

  • OpenWorkItem

  • PublishSymbols

  • RevertWorkspace

  • SetBuildProperties

  • SharedResourceScope

  • SyncWorkspace

  • TfsBuild

  • UpdateBuildNumber

  • WriteBuildError

  • WriteBuildInformation<T>

  • WriteBuildMessage

  • WriteBuildWarning

Ausführen grundlegender Aufgaben

Sie können Team Foundation Build-Aktivitäten für die Ausführung folgender Aufgaben verwenden:

  • Abrufen der Werte von Umgebungsvariablen

  • Abrufen von Pfaden zu Dateien im Arbeitsbereich

  • Arbeiten mit Verzeichnissen

  • Abrufen des Pfads zum Build-Agent-Arbeitsverzeichnis

  • Herunterladen von Dateien, die sich nicht in einem Arbeitsbereich befinden

  • Suchen von Dateien

  • Schreiben von Warnungen, Fehlern, Meldungen und anderen Daten in das Buildprotokoll

  • Schreiben von Metadaten über den Build

Abrufen der Werte der Umgebungsvariablen (ExpandEnvironmentVariables-Aktivität)

Verwenden Sie die ExpandEnvironmentVariables-Aktivität, um eine oder mehrere Umgebungsvariablen auf einem Buildserver aufzulösen. Die Umgebungsvariablen werden auf dem Build-Agent gelesen, wenn sich die Aktivität innerhalb einer AgentScope-Sequenz befindet; andernfalls werden die Umgebungsvariablen auf dem Buildcontroller gelesen.

ExpandEnvironmentVariables Result (String)-Eigenschaft

Gibt das Ergebnis des Vorgangs zurück. Beispiel: The temp directory on machine BLDSERV3 is C:\windows\SERVIC~2\NETWOR~1\AppData\Local\Temp.

ExpandEnvironmentVariables-Argumenteigenschaften

  • Input (String): Sie müssen die Zeichenfolge angeben, die die aufzulösenden Umgebungsvariablen enthält. Sie müssen jede Umgebungsvariable formatieren, indem Sie eine MSBuild-Eigenschaft angeben, anstatt die Windows-Prozentschreibweise zu verwenden. Beispiel: "The temporary directory on machine $(COMPUTERNAME) is $(TEMP)."

  • AdditionalVariables (IDictionary<TKey, TValue><String,String>): Sie können ein IDictionary-Objekt angeben, das zusätzliche Variablen (als Schlüssel) enthält, die aufgelöst werden sollen.

Zurück nach oben

Abrufen von Pfaden zu Dateien im Arbeitsbereich

Jeder Build verfügt über einen Arbeitsbereich Versionskontrolle, der auf der Registerkarte Arbeitsbereich der Builddefinition definiert ist. Der Arbeitsbereich stellt dem Build den Zugriff auf Quellcodedateien und andere Dateien bereit, die der Build vom Versionskontrollsystem benötigt. Team Foundation Build stellt zwei Aktivitäten bereit, die Sie zum Arbeiten mit Dateien im Buildarbeitsbereich verwenden können: ConvertWorkspaceItem und ConvertWorkspaceItems.

Weitere Informationen zu Buildarbeitsbereichen finden Sie unter Erstellen einer einfachen Builddefinition.

Tipp

Eine ausführliche schrittweise Anleitung zur Verwendung der ConvertWorkspaceItem-Aktivität in einem typischen Szenario finden Sie unter Steuern, wo das Buildsystems die Binärdateien ablegt.

Abrufen des Pfads zu einer Datei in einem Arbeitsbereich (ConvertWorkspaceItem-Aktivität)

Verwenden Sie die ConvertWorkspaceItem-Aktivität, um einen Serverpfad in einen lokalen Pfad auf dem Build-Agent zu konvertieren oder um einen lokalen Pfad auf dem Build-Agent in einen Serverpfad zu konvertieren.

ConvertWorkspaceItem Result (String)-Eigenschaft

Gibt den konvertierten Pfad zurück.

ConvertWorkspaceItem-Argumenteigenschaften

  • Input (String): Sie müssen den Pfadwert angeben, den Sie konvertieren möchten.

  • Workspace (Workspace): Sie müssen einen Verweis auf den Workspace bereitstellen, der die Datei enthält. In den meisten Fällen sollten Sie diese Eigenschaft auf die Variable festlegen, die Sie in der Result-Eigenschaft der CreateWorkspace-Aktivität initialisieren. Wenn Sie einen Buildprozess erstellen, der auf DefaultTemplate.xaml basiert, sollten Sie die Workspace-Variable verwenden.

  • Richtung

    • Konvertieren eines Serverpfads in einen lokalen Pfad: Wählen Sie in der Direction-Eigenschaft die Option ServerToLocal aus, und geben Sie dann den Pfad zur Datei auf dem Server in der Eigenschaft Input (String) an.

      Zum Beispiel kann Ihr Team allgemeine Hilfsprogramme in folgendem Verzeichnis speichern: $/OurTeam/BuildProcess/Util. Sie können einen benutzerdefinierten Buildprozess erstellen, der nach dem Kompilieren der Binärdateien das Hilfsprogramm ScanBinaries.exe ausführt. Wenn $/OurTeam/BuildProcess/Util auf der Registerkarte Arbeitsbereich der Builddefinition zugeordnet ist, können Sie $/OurTeam/BuildProcess/Util/ScanBinaries.exe in der Input-Eigenschaft angeben, um den lokalen Pfad zum Hilfsprogramm aus der Result (String)-Eigenschaft abzurufen.

    • Konvertieren eines lokalen Pfads in einen Serverpfad: Wählen Sie in der Direction-Eigenschaft die Option ServerToLocal aus, und geben Sie dann den lokalen Pfad zur Datei auf dem Build-Agent in der Input-Eigenschaft an.

Abrufen der Pfade zu Dateien in einem Arbeitsbereich (ConvertWorkspaceItems-Aktivität)

Verwenden Sie die ConvertWorkspaceItems-Aktivität, um einen Serverpfad in einen lokalen Pfad auf dem Build-Agent zu konvertieren oder um einen lokalen Pfad auf dem Build-Agent in einen Serverpfad zu konvertieren.

ConvertWorkspaceItems Result (IList<String>)-Eigenschaft

Gibt die konvertierten Pfadwerte zurück.

ConvertWorkspaceItems-Argumenteigenschaften

  • Input (IEnumerable<T><String>): Sie müssen die Pfadwerte angeben, die Sie konvertieren möchten.

  • Workspace (Workspace): Sie müssen einen Verweis auf den Workspace bereitstellen, der die Dateien enthält. In den meisten Fällen sollten Sie diese Eigenschaft auf die Variable festlegen, die Sie in der Result-Eigenschaft der CreateWorkspace-Aktivität initialisieren.

    Tipp

    Wenn Sie einen Buildprozess erstellen, der auf DefaultTemplate.xaml basiert, sollten Sie die Workspace-Variable verwenden.

  • Direction: Wählen Sie einen der folgenden Werte aus:

    • Wählen Sie ServerToLocal aus, wenn Sie eine Auflistung von Serverpfadwerten in der Input-Eigenschaft angeben und die Result-Eigenschaft eine Liste von lokalen Pfadwerten zurückgeben soll.

    • Wählen Sie LocalToServer aus, wenn Sie eine Auflistung von lokalen Pfadwerten in der Input-Eigenschaft angeben und die Result-Eigenschaft eine Liste von lokalen Pfadwerten zurückgeben soll.

Arbeiten mit Verzeichnissen

Sie können für die Arbeit mit Verzeichnissen in Team Foundation Build mehrere Aktivitäten verwenden.

Tipp

Wenn Sie mit Verzeichnissen arbeiten müssen, die Teil des Arbeitsbereichs Versionskontrolle des Builds sind, sollten Sie stattdessen die Arbeitsbereich-Aktivitäten verwenden. Weitere Informationen finden Sie unter Abrufen der Pfade zu Dateien im Arbeitsbereich.

Erstellen eines Verzeichnisses (CreateDirectory-Aktivität)

Verwenden Sie die CreateDirectory-Aktivität, um ein Verzeichnis zu erstellen. Den Namen des Verzeichnisses geben Sie in der Directory (String)-Eigenschaft an.

Kopieren eines Verzeichnisses (CopyDirectory-Aktivität)

Verwenden Sie die CopyDirectory-Aktivität, um den gesamten Inhalt eines Verzeichnisses, das Sie in der Source (String)-Eigenschaft angeben, rekursiv in ein anderes Verzeichnis, das Sie in der Destination (String)-Eigenschaft angeben, zu kopieren. Das Verzeichnis, das Sie in der Destination-Eigenschaft angeben, muss bereits vorhanden sein. Leere Verzeichnisse und Unterverzeichnisse werden nicht kopiert.

Löschen eines Verzeichnisses (DeleteDirectory-Aktivität)

Verwenden Sie die DeleteDirectory-Aktivität, um ein Verzeichnis zu löschen, dessen Namen Sie in der Directory (String)-Eigenschaft angeben. Wenn das zu löschende Verzeichnis Unterverzeichnisse enthält, müssen Sie die Recursive (Boolean)-Eigenschaft auf True festlegen; andernfalls schlägt der Build fehl.

Abrufen des Pfads zum Build-Agent-Arbeitsverzeichnis (GetBuildDirectory-Aktivität)

Verwenden Sie die GetBuildDirectory-Aktivität, um den exakten Pfad zum Arbeitsverzeichnis des Build-Agents aus der Result (String)-Eigenschaft abzurufen. Sie können diese Aktivität nur innerhalb einer AgentScope-Aktivität verwenden.

Zurück nach oben

Herunterladen von Dateien, die sich nicht in einem Arbeitsbereich befinden

Verwenden Sie die DownloadFiles-Aktivität, um eine oder mehrere Dateien herunterzuladen. Ignorieren Sie die DownloadFile-Aktivität.

DownloadFiles-Aktivität

Verwenden Sie die DownloadFiles-Aktivität, um eine oder mehrere Dateien aus der Versionskontrolle herunterzuladen.

Tipp

Wenn die Dateien, die Sie herunterladen möchten, sich im Arbeitsbereich des Builds befinden, sollten Sie über die ConvertWorkspaceItem-Aktivität auf die Dateien zugreifen.

DownloadFiles-Argumenteigenschaften

  • LocalPath (String) Sie müssen einen Wert angeben:

    • Wenn Sie eine einzelne Datei herunterladen, geben Sie den lokalen Pfad und den Namen an, den Sie der lokalen Kopie der Downloaddatei geben möchten, z. B. "c:\Docs\readme.txt".

    • Wenn Sie mehrere Dateien herunterladen, geben Sie den lokalen Pfad zu dem Verzeichnis an, in das Sie die Dateien herunterladen möchten, z. B. "c:\Docs\".

  • ServerPath (String) Sie müssen einen Wert angeben:

    • Wenn Sie eine einzelne Datei herunterladen, geben Sie den Serverpfad und den Namen der Downloaddatei an, z. B. "$/Docs/readme.txt".

    • Wenn Sie mehrere Dateien herunterladen, geben Sie den Serverpfad zu dem Verzeichnis an, das die Downloaddateien enthält, z. B. "$/Docs/".

  • Recursion (RecursionType):

    • OneLevel: Lädt die Datei oder die Dateien in das Verzeichnis herunter, das Sie in der ServerPath-Eigenschaft angeben.

    • Full: Lädt die Dateien aus dem Verzeichnis, das Sie in der ServerPath-Eigenschaft angeben, und die Dateien aus allen Unterverzeichnissen herunter.

  • Version (String): Sie können eine Versionsspezifikation angeben. Um die aktuelle Version herunterzuladen, behalten Sie für diese Eigenschaft den Wert Microsoft.TeamFoundation.VersionControl.Client.VersionSpec.Latest.DisplayString bei. Weitere Informationen zu Versionsspezifikationen finden Sie unter Befehlszeilensyntax (Versionskontrolle).

  • DeletionID (Int32): Sie müssen diese Eigenschaft nur angeben, wenn Sie eine Datei herunterladen, die aus der Versionskontrolle gelöscht wurde. Sie können diesen Wert interaktiv abrufen, indem Sie in der Eingabeaufforderung tf dir /deleted eingeben. (Weitere Informationen finden Sie unter Befehl Dir.) Team Foundation Build bietet jedoch keine integrierte Aktivität, um eine DeletionID abzurufen. Um diese Eigenschaft zu verwenden, müssen Sie eine benutzerdefinierte Aktivität abrufen oder erstellen, die diese Funktionalität bereitstellt.

Zurück nach oben

DownloadFile-Aktivität

Ignorieren Sie die DownloadFile-Aktivität. Die DownloadFiles-Aktivität ist die einfachste Möglichkeit, eine oder mehrere Dateien herunterzuladen.

Suchen von Dateien (FindMatchingFiles-Aktivität)

Verwenden Sie die FindMatchingFiles-Aktivität, um Dateien zu suchen. Geben Sie die Suchkriterien in der MatchPattern (String)-Eigenschaft an. In dieser Eigenschaft können Sie ein Argument mit folgenden Elementen angeben:

  • Syntax, die vom searchPattern-Argument der GetFiles(String, String) Directory-Methode unterstützt wird.

  • **, um eine rekursive Suche anzugeben. Beispiel:

    • Um das Quellverzeichnis nach Textdateien zu durchsuchen, können Sie für die MatchPattern-Eigenschaft eine Angabe machen wie: String.Format("{0}\**\*.txt", SourcesDirectory).

    • Um im Quellverzeichnis in einen oder mehreren Unterverzeichnissen nach Textdateien mit der Bezeichnung txtfiles zu suchen, können Sie für die MatchPattern-Eigenschaft eine Angabe machen wie: String.Format("{0}\**\txtfiles\*.txt", SourcesDirectory).

Sie können das Ergebnis des Vorgangs in der < StringResult-Eigenschaft IEnumerable<T> (>) erfassen.

Schreiben von Warnungen, Fehlern, Meldungen und anderen Daten in das Buildprotokoll

WriteBuildMessage-Aktivität

Verwenden Sie die WriteBuildMessage-Aktivität, um eine Informationsmeldung in das Buildprotokoll zu schreiben. Sie müssen die Meldung in der Message (String)-Eigenschaft angeben. Sie können zusätzlich die Wichtigkeit der Meldung angeben, indem Sie den Wert der Importance (BuildMessageImportance)-Eigenschaft bearbeiten.

Tipp

  • Benutzer des Buildprozesses können ggf. auf die Filter zur Reduktion des Ausführlichkeitsgrads zurückgreifen, um einen Informationsüberfluss hinsichtlich der Anzeige der gewünschten Daten und der im Data Warehouse vorhandenen Daten zu vermeiden. Sie können den Filterungsvorgang effektiver gestalten, indem Sie einen konsequenten Ansatz beim Festlegen der Importance-Eigenschaft für die Buildmeldungen verfolgen. Weitere Informationen finden Sie unter Verwalten der Buildinformationen und des Steuerelement-Ausführlichkeitsgrads.

  • Wenn Sie die Standardeinstellungen verwenden, wird die Meldung nicht in das Buildprotokoll geschrieben. Um dieses Problem zu beheben, führen Sie einen der folgenden Schritte aus:

    • Legen Sie die WriteBuildMessage Importance-Eigenschaft auf Microsoft.TeamFoundation.Build.Client.BuildMessageImportance.High fest.

    • Legen Sie auf der Registerkarte Prozess der Builddefinition den Protokollierungsausführlichkeit-Prozessparameter auf Detailed oder Diagnostic fest.

WriteBuildWarning-Aktivität

Verwenden Sie die WriteBuildWarning-Aktivität, um eine Warnmeldung in das Buildprotokoll zu schreiben. Warnungen werden mit einem gelben Ausrufezeichen im Fenster Buildergebnisse angezeigt. Sie müssen die Meldung in der Message (String)-Eigenschaft angeben.

Die Buildwarnungen werden nur protokolliert, wenn Ihr Team den Ausführlichkeitsgrad auf Minimal oder höher festlegt. Weitere Informationen finden Sie unter Verwalten der Buildinformationen und des Steuerelement-Ausführlichkeitsgrads.

WriteBuildError-Aktivität

Verwenden Sie die WriteBuildError-Aktivität, um eine Fehlermeldung in das Buildprotokoll zu schreiben. Fehler werden mit einem roten Ausrufezeichen im Fenster Buildergebnisse angezeigt. Wird ein Fehler in das Buildprotokoll geschrieben, wird der Build bestenfalls als Partially Succeeded klassifiziert. Sie müssen die Meldung in der Message (String)-Eigenschaft angeben.

Buildfehler werden immer protokolliert, unabhängig von den Ausführlichkeitsgradseinstellungen. Weitere Informationen finden Sie unter Verwalten der Buildinformationen und des Steuerelement-Ausführlichkeitsgrads.

WriteBuildInformation<T>-Aktivität

Verwenden Sie die WriteBuildInformation<T>-Aktivität, um ein Objekt in das Buildprotokoll aufzunehmen. Wenn ein Benutzer das Protokoll im Fenster Buildergebnisse anzeigt, wird das Objekt mittels Reflektion gerendert.

WriteBuildInformation<T>-Argumenteigenschaften

  • Value (Object): Sie müssen das Objekt angeben, das in das Buildprotokoll aufgenommen werden soll. Damit das Objekt im Fenster Buildergebnisse angezeigt wird, muss das Objekt IBuildInformationNode implementieren und Type auf einen der folgenden InformationTypes-Werte festgelegt werden:

    • ActivityProperties

    • ActivityTracking

    • AgentScopeActivityTracking

    • BuildError

    • BuildMessage

    • BuildProject

    • BuildStep

    • BuildWarning

    • ExternalLink

    • OpenedWorkItem

  • ParentToBuildDetail: Sie können False angeben, um das übergeordnete Element des Objekts zum übergeordneten Element der Aktivität zu machen, oder Sie können True angeben, um das IBuildDetail-Objekt zum übergeordneten Element zu machen.

    Die Einstellung der Eigenschaft beeinflusst die Anzeige der Informationen im Fenster Buildergebnisse. Wenn Sie False angeben, erfolgen Einzug und Ausrichtung der Informationen zusammen mit der Ausgabe der anderen Aktivitäten, die vor oder hinter der WriteBuildInformation<T>-Aktivität stehen und sich auf derselben Ebene befinden. Wenn Sie True angeben, werden die Informationen nicht eingezogen.

Zurück nach oben

Schreiben von Metadaten in das Data Warehouse

Sie können Metadaten über den Build in das Data Warehouse schreiben:

  • Schreiben der Buildnummer (UpdateBuildNumber-Aktivität)

  • Schreiben wichtiger Datenpunkte über den Build (SetBuildProperties-Aktivität)

Tipp

Wenn die Aktivitäten nicht die von Ihnen gewünschten Metadaten unterstützen, können Sie die GetBuildDetail-Aktivität verwenden, um einen Verweis auf das IBuildDetail-Objekt zu erhalten und die Daten dann direkt über diesen Verweis dem Objekt zuzuweisen.

Schreiben der Buildnummer (UpdateBuildNumber-Aktivität)

Verwenden Sie die UpdateBuildNumber-Aktivität, um die Buildnummer (oder den Namen) des Builds festzulegen. Bei dieser Aktivität werden folgende Schritte ausgeführt:

  1. Erstellen einer Buildnummer auf der Basis eines Ausdrucks zur Festlegung des Buildnummernformats. Der Buildprozess nimmt diesen Ausdruck i. d. R. von einem Workflow-Argument entgegen, das über einen Parameter auf der Registerkarte Prozess einer Builddefinition bereitgestellt wird.

  2. Festlegen der Buildnummer (oder des Buildnamens) durch Schreiben des Ergebniswerts in die BuildNumber-Eigenschaft.

UpdateBuildNumber Result (String)-Eigenschaft

Result: Gibt den neuen BuildNumber-Wert zurück.

UpdateBuildNumber-Eigenschaften

  • BuildNumberFormat (String): Sie müssen einen Ausdruck angeben, der das Buildnummernformat angibt. Informationen zur Syntax dieses Ausdrucks finden Sie unter Arbeiten mit Buildnummern.

Zurück nach oben

Schreiben wichtiger Datenpunkte über den Build (SetBuildProperties-Aktivität)

Verwenden Sie SetBuildProperties, um wichtige Datenpunkte in das IBuildDetail-Objekt zu schreiben, das die Speicherung der Daten zu den einzelnen Builds im Data Warehouse verwaltet. Ein Großteil dieser Daten wird dem Benutzer im Fenster Buildergebnisse angezeigt.

SetBuildProperties-Eigenschaften

  • PropertiesToSet: Sie müssen die Kontrollkästchen für die Namen der Eigenschaften auswählen, die Sie festlegen möchten.

  • BuildNumber (String): Sie können die BuildNumber des Builds festlegen; dabei handelt es sich sozusagen um den Namen des Builds.

    Tipp

    Wenn Sie diesen Wert auf der Grundlage von benutzerspezifischen Einstellungen auf der Registerkarte Prozess der Builddefinition festlegen möchten, sollten Sie die UpdateBuildNumber-Aktivität anstelle dieser Eigenschaft verwenden.

  • CompilationStatus (BuildPhaseStatus): Sie können den Kompilierungsstatus festlegen (CompilationStatus). (Die MSBuild-Aktivität legt diesen Wert auch automatisch fest.)

  • DropLocation (String): Sie können den Ablagespeicherort in der DropLocation-Eigenschaft erfassen.

    Tipp

    Wenn Sie diese Eigenschaft festlegen, wird kein Ablagespeicherort erstellt. Stattdessen wird über diese Eigenschaft der Speicherort des Ablageordners im Data Warehouse gespeichert, den Sie i. d. R. mit der CreateDirectory-Aktivität erstellen.

  • KeepForever (Boolean): Sie können die KeepForever-Eigenschaft auf True festlegen, wenn Sie die Einstellungen auf der Registerkarte Beibehaltungsrichtlinie der Builddefinition ignorieren möchten, und der abgeschlossene Build unbegrenzt erhalten bleiben soll.

  • LabelName (String): Sie können die LabelName-Eigenschaft festlegen, um die Bezeichnung zu erfassen, die Sie zur Kennzeichnung des Builds in den Quellcodedateien der Versionskontrolle verwendet haben. Normalerweise legen Sie diese Eigenschaft fest, um eine Überstimmung mit dem Wert der Name-Eigenschaft der LabelWorkspace-Aktivität zu erzielen.

    Wichtig

    Team Foundation Build benötigt diese Daten, um den Builds die Changesets und Arbeitsaufgaben zuzuordnen. Wenn Sie diese Daten nicht bereitstellen, schlägt die AssociateChangesetsAndWorkItems-Aktivität fehl.

  • LogLocation (String): Sie können die LogLocation-Eigenschaft verwenden, um den UNC-Dateipfad des Ordners zu erfassen, in dem der Buildprozess die Protokolldatei ablegt.

    Tipp

    Für einen benutzerdefinierten Buildprozess benötigen Sie diese Eigenschaft meist nicht. Diese Eigenschaft ist in erster Linie für die Verwendung durch die UpgradeTemplate.xaml-Datei gedacht, um Vorgänger-Buildprozesse zu unterstützen.

  • Quality (String): Sie können die Qualität des Builds in der Quality-Eigenschaft erfassen.

  • SourceGetVersion (String): Sie können die SourceGetVersion-Eigenschaft verwenden, um die Versionsspezifikation zu erfassen, für die Build-Quellen abgerufen werden.

  • Status (BuildStatus): Sie können den allgemeinen Status des Builds in der Status-Eigenschaft erfassen. Beispielsweise können Sie diese Eigenschaft verwenden, um anzugeben, ob der Build erfolgreich war oder fehlgeschlagen ist.

  • TestStatus (BuildPhaseStatus): Verwenden Sie die TestStatus-Eigenschaft, um den allgemeinen Status von Tests zu erfassen, die für diesen Build vorgenommen wurden. Beispielsweise können Sie mit dieser Eigenschaft angeben, ob die Tests für diesen Build erfolgreich waren oder fehlgeschlagen sind.

Zurück nach oben

Steuern des Buildprozesses

Mit Team Foundation Build-Aktivitäten können Sie den Buildprozess folgendermaßen steuern:

  • Ausführen von Build-Agent-Aktivitäten

  • Verwenden einer benannten Mutex-Struktur, um einen threadsicheren Prozess zu implementieren

  • Einschränken bestimmter Abschnitte des Buildprozesses nach der Ursache (Trigger)

Aktivitäten auf dem Build-Agent ausführen (AgentScope-Aktivität)

Verwenden Sie die AgentScope-Aktivität, um festzulegen, welche Teile des Buildprozesses auf dem Build-Agent ausgeführt werden sollen.

AgentScope-Argumenteigenschaften

  • Agent-Auswahl

    • MaxWaitTime (TimeSpan): Sie können die maximale Dauer angeben, die ein Buildprozess darauf wartet, bis ein Build-Agent verfügbar ist. Sie können einen Wert im Format hh: mm: ss eingeben. Beispielsweise schlägt der Build mit einem Timeoutfehler fehl, wenn Sie den Wert 01:30:45 angeben und der Build nach 1 Stunde, 30 Minuten und 45 Sekunden noch keinem Build-Agent zugewiesen wurde. Geben Sie den Wert 00:00:00 an, wenn Sie für den Buildcontroller eine unbegrenzte Zeitspanne zum Suchen eines Build-Agents für die Verarbeitung der Builddefinition festlegen möchten.

      Wichtig

      Sie können die Sicherung der Buildwarteschlange vermeiden, indem Sie einen Wert ungleich 0 in der MaxWaitTime-Eigenschaft angeben.

    • ReservationSpec (AgentReservationSpec): Sie können festlegen, welche Build-Agent-Arten für die Verarbeitung der Aktivitäten aus dieser Aktivität verwendet werden dürfen. Beispielsweise können Sie angeben, dass nur Build-Agents mit einem bestimmten Tag verwendet werden, um die Aktivitäten innerhalb der AgentScope-Aktivität zu verarbeiten.

  • Ausführung

    • MaxExecutionTime (TimeSpan): Sie können die maximale Dauer angeben, die zum Abschluss der AgentScope-Aktivität zulässig ist. Sie können einen Wert im Format hh: mm: ss eingeben. Beispielsweise schlägt der Build mit einem Timeoutfehler fehl, wenn Sie den Wert 04:30:15 angeben und die Verarbeitung durch den Build-Agent nach 4 Stunden, 30 Minuten und 15 Sekunden nicht abgeschlossen ist. Geben Sie den Wert 00:00:00 an, wenn Sie eine unbegrenzte Zeitspanne für die Verarbeitung des Builds durch den Build-Agent festlegen möchten.

      Tipp

      Sie können die Sicherung der Buildwarteschlange vermeiden, indem Sie einen Wert ungleich 0 in der MaxExecutionTime-Eigenschaft angeben.

  • Umfang

    • DataToIgnore: Ignorieren Sie diese Eigenschaft.

Zurück nach oben

Verwenden einer benannten Mutexstruktur, um einen threadsicheren Prozess zu implementieren (SharedResourceScope-Aktivität)

Verwenden Sie die SharedResourceScope-Aktivität, um eine benannte Mutexstruktur (gegenseitiger Ausschluss) zu implementieren. Das Segment des Buildprozesses, das Sie in dieser Aktivität ablegen, gilt als "threadsicher".

Ein typisches Anwendungsbeispiel für diese Aktivität ist die Einbeziehung jener Teile des Buildvorgangs, die auf eine freigegebene Ressource zugreifen müssen, auf die jeweils immer nur ein Prozess zugreifen darf. Beispielsweise sollen mehrere Builds nacheinander in eine einzelne Textdatei auf einer Dateifreigabe schreiben. Um sicherzustellen, dass diese Art von Prozess ordnungsgemäß funktioniert, sollten Sie den Prozess innerhalb einer SharedResourceScope-Aktivität implementieren.

Ein weiteres Beispiel finden Sie in der Vorlage DefaultTemplate.xaml. Dort ist der Aufruf der PublishSymbols-Aktivität in eine SharedResourceScope-Aktivität eingebettet:

  1. Sequenz (Sequence) >

  2. Auf Agent ausführen (AgentScope) >

  3. Kompilieren, Testen und Zuordnen von Changesets und Arbeitsaufgaben (TryCatch [Try]) >

  4. Sequenz (Sequence) >

  5. Betroffene Tests abrufen, Quellen indizieren und Symbole veröffentlichen (Parallel) >

  6. SourceAndSymbolServerSettings.IndexSources oder SourceAndSymbolServerSettings.HasSymbolStorePath (If [Then]) >

  7. Quellen indizieren und Symbole veröffentlichen für gestartete Builds (InvokeForReason) >

  8. SourceAndSymbolServerSettings.HasSymbolStorePath (If [Then]) >

  9. Symbole veröffentlichen (TryCatch [Try]) >

  10. Zugriff auf den Symbolspeicher synchronisieren (SharedResourceScope) >

  11. Symbole veröffentlichen (PublishSymbols)

Weitere Informationen zur Navigation in dieser Struktur finden Sie unter Navigieren in einem komplexen Windows Workflow.

SharedResourceScope-Argumenteigenschaften

  • ResourceName (String): Sie müssen einen Wert angeben. Alle Instanzen der SharedResourceScope-Aktivitäten werden nacheinander ausgeführt, wenn sie denselben ResourceName-Wert in der Teamprojektauflistung aufweisen (selbst wenn sie sich in anderen Builddefinitionsvorlagen befinden).

  • MaxExecutionTime (TimeSpan): Sie können die maximale Dauer angeben, die zum Abschluss dieser SharedResourceScope-Aktivität zulässig ist. Sie können einen Wert im Format hh: mm: ss eingeben. Beispielsweise schlägt der Build mit einem Timeoutfehler fehl, wenn Sie den Wert 04:30: 15 angeben und die SharedResourceScope-Aktivität nach 4 Stunden, 30 Minuten und 15 Sekunden noch nicht abgeschlossen ist. Geben Sie den Wert 00:00:00 an, wenn Sie keine Zeitbeschränkung für die Bearbeitung der SharedResourceScope-Aktivität festlegen möchten.

    Tipp

    Sie können die Sicherung der Buildwarteschlange vermeiden, indem Sie einen Wert ungleich 0 in der MaxExecutionTime-Eigenschaft angeben.

  • MaxWaitTime (TimeSpan): Sie können die maximale Zeitdauer angeben, die der Buildprozess in der Warteschlange wartet, um die SharedResourceScope-Aktivität zu verarbeiten. Sie können einen Wert im Format hh: mm: ss eingeben. Beispielsweise schlägt der Build mit einem Timeoutfehler fehl, wenn Sie den Wert 01:30:45 angeben und die SharedResourceScope-Aktivität nach 1 Stunden, 30 Minuten und 45 Sekunden noch nicht abgeschlossen ist. Geben Sie den Wert 00:00:00 an, wenn Sie keine Zeitbeschränkung für den Verbleib des Buildprozesses in der Warteschlange festlegen möchten.

    Tipp

    Sie können die Sicherung der Buildwarteschlange vermeiden, indem Sie einen Wert ungleich 0 in der MaxWaitTime-Eigenschaft angeben.

Zurück nach oben

Einschränken bestimmter Abschnitte des Buildprozesses nach der Ursache (Trigger) (InvokeForReason-Aktivität)

Verwenden Sie die InvokeForReason-Aktivität, um ein Segment des Buildprozesses nur in Builds auszuführen, die aus einem bestimmten Grund ausgeführt wurden. Buildgründe werden i. d. R. über einen Trigger festgelegt, den der Benutzer auf der Registerkarte Trigger der Builddefinition auswählen kann. Sie können in der Reason-Eigenschaft einen oder mehrere Werte angeben. Weitere Informationen finden Sie unter Angeben der Buildtrigger und Gründe.

Zurück nach oben

Kompilieren, Testen und Ausführen weiterer Aufgaben

Sie können Team Foundation Build-Aktivitäten verwenden, um Binärdateien zu kompilieren, Tests und weitere Aufgaben auszuführen:

  • Verwenden von MSBuild, um Binärdateien zu kompilieren, Codeanalysen und weitere Aufgaben auszuführen

  • Verwenden von MSTest zur Durchführung von Tests

  • Abrufen einer Liste der Tests, die vom Build betroffen sind

Verwenden von MSBuild, um Binärdateien zu kompilieren, Codeanalysen und weitere Aufgaben auszuführen (MSBuild-Aktivität)

Verwenden Sie die MSBuild-Aktivität, um Binärdateien zu kompilieren, Codeanalysen auszuführen und von allen weiteren MSBuild-Funktionen Gebrauch zu machen.

MSBuild Result

Keine der Eigenschaften dieser Aktivität gibt ein Ergebnis zurück. Allerdings setzt diese Aktivität CompilationStatus auf Failed, wenn Kompilierungsfehler protokolliert werden.

MSBuild-Argumenteigenschaften

  • AdditionalVCOverrides (String): Wenn Sie GenerateVsPropsFile auf True festlegen, wird der Inhalt dieser Eigenschaft in die generierte .vsprops-Datei eingebettet.

  • CommandLineArguments (String): Sie können Befehlszeilenargumente angeben, die Sie an MSBuild übergeben möchten.

  • Configuration (String): Sie können die Build-Konfiguration angeben. Beispielsweise “debug” oder “release”.

  • GenerateVSPropsFile (Boolean): Wenn diese Eigenschaft auf True festgelegt ist, generiert MSBuild eine Standard-.vsprops-Datei für die Übergabe an C++-Projekte. Diese Datei enthält das Ausgabeverzeichnis für C++-Projekte und was immer Sie in der AdditionalVCOverrides-Eigenschaft angegeben haben.

  • LogFile (String): Sie können den Namen der Protokolldatei angeben, die von MSBuild erstellt werden soll.

  • LogFileDropLocation (String): Sie können den vollqualifizierten UNC-Pfad des Verzeichnisses angeben, in dem Sie die MSBuild-Protokolldatei ablegen möchten.

  • MaxProcesses (Int32): Sie können die maximale Anzahl von Prozessen angeben, die von MSBuild erstellt werden.

  • OutDir (String) Sie können das Verzeichnis angeben, in dem MSBuild die kompilierten Binärdateien ablegt. Weitere Informationen finden Sie unter Steuern, wo das Buildsystems die Binärdateien ablegt.

  • Platform (String): Sie können die Plattform angeben, für die MSBuild einen Build erstellt. Beispielsweise “Any CPU”, “x86” oder “x64”.

  • Project (String): Sie können die Projektmappe oder das Codeprojekt angeben, die bzw. das von MSBuild erstellt wird.

  • ResponseFile (String): Sie können die Antwortdatei angeben, die von MSBuild verwendet wird.

  • RunCodeAnalysis (CodeAnalysisOption): Sie können angeben, ob die Codeanalyse immer, nie oder entsprechend den Projekteinstellungen ausgeführt werden soll.

  • Targets (IEnumerable<T><String>): Sie können die Ziele angeben, die erstellt werden sollen.

  • TargetsNotLogged (IEnumerable<T><String>): Sie können die Ziele angeben, für die keine ProjectStarted-Ereignisse protokolliert werden sollen.

  • ToolPath (String): Sie können den Toolpfad angeben.

  • ToolPlatform (ToolPlatform): Sie können die Toolplattform angeben. Geben Sie Microsoft.TeamFoundation.Build.Workflow.Activities.ToolPlatform.Auto an, um die Plattform auf Basis des aktuellen Betriebssystems zu ermitteln.

  • Verbosity (BuildVerbosity): Sie können die Ausführlichkeit des Protokolls angeben, das von MSBuild generiert wird.

Weitere Informationen zu einer Vielzahl von MSBuild-Optionen, auf die sich die MSBuild-Eigenschaften auswirken, finden Sie unter MSBuild-Befehlszeilenreferenz.

Zurück nach oben

Ausführen von Tests (MSTest-Aktivität)

Mit dieser Aktivität können Sie Tests mit MSTest.exe ausführen.

Core MSTest-Eigenschaften

Zunächst legen Sie fest, wie Sie die Tests ausführen möchten. Geben Sie dann Werte für die entsprechenden Eigenschaften an.

  • Um Tests in Testcontainern auszuführen (empfohlen), verwenden Sie die folgenden Eigenschaften:

    • TestContainers (IEnumerable<String>): Sie müssen die Testcontainer der Tests angeben, die Sie ausführen möchten. Diese Eigenschaft entspricht der /testcontainer-Option des Befehls MSTest.exe. Weitere Informationen finden Sie unter /testcontainer.

    • SearchPathRoot (String): Sie können den Stamm des Pfads für das Verzeichnis angeben, in dem nach Testcontainern und ihren Abhängigkeiten gesucht werden soll. Wenn Sie keinen Wert angeben, versucht die MSTest-Aktivität die Dateien an den typischen Speicherorten zu finden.

    • TestSettings (String): Sie können eine Testlaufkonfigurationsdatei angeben. Diese Eigenschaft entspricht der /testsettings-Option des Befehls MSTest.exe. Weitere Informationen finden Sie unter /testsettings.

  • Um Tests in Testlisten auszuführen, verwenden Sie die folgenden Eigenschaften:

    • TestLists (IEnumerable<String>): Sie müssen die Testlisten angeben, die Sie ausführen möchten. Diese Eigenschaft entspricht der /testlist-Option des Befehls MSTest.exe. Weitere Informationen finden Sie unter /testlist und Definieren von Testlisten zum Gruppieren von Tests.

    • TestMetadata (String): Sie müssen die Metadatendatei angeben, die die Testlisten enthält, die Sie ausführen möchten. Diese Eigenschaft entspricht der /testmetadata-Option des Befehls MSTest.exe. Weitere Informationen finden Sie unter /testmetadata.

MSTest-Filtereigenschaften

Sie können anhand der folgenden Eigenschaften festlegen, welche Tests ausgeführt werden sollen:

  • Category (String): Sie können Tests nach ihren Testkategorien filtern. Diese Eigenschaft entspricht der /category-Option des Befehls MSTest.exe. Weitere Informationen finden Sie unter /category und Definieren von Testkategorien zum Gruppieren von Tests.

  • MaxPriority (Int32): Sie können die maximale Priorität der Tests angeben, die Sie ausführen möchten. Nur Tests, deren Priorität kleiner oder gleich diesem Wert ist, werden ausgeführt. Sie müssen eine positive ganze Zahl angeben, die größer oder gleich dem Wert der MinPriority-Eigenschaft ist, oder Sie geben -1 an, wenn Sie keine maximale Priorität angeben möchten.

    Tipp

    Wenn Sie den Tests Prioritäten zugewiesen haben, können Sie mit den Eigenschaften MinPriority und MaxPriority einen gesunden Ausgleich zwischen gründlichen Tests und schnelleren Builds schaffen.

  • MinPriority (Int32): Sie können die minimale Priorität der Tests angeben, die Sie ausführen möchten. Nur Tests, deren Priorität größer oder gleich diesem Wert ist, werden ausgeführt. Sie müssen eine positive ganze Zahl angeben, die kleiner oder gleich dem Wert der MaxPriority-Eigenschaft ist, oder Sie geben -1 an, wenn Sie keine minimale Priorität angeben möchten.

  • TestNames (IEnumerable<String>): Sie können die Namen der Tests angeben, die Sie ausführen möchten. Diese Eigenschaft entspricht der /test-Option des Befehls MSTest.exe. Weitere Informationen finden Sie unter /test.

MSTest-Veröffentlichungseigenschaften

Sie können die folgenden Eigenschaften verwenden, um die Testergebnisse im Data Warehouse zu veröffentlichen:

  • Publish (Boolean): Sie müssen diese Eigenschaft auf True festlegen, wenn Sie die Testergebnisse veröffentlichen möchten.

  • Flavor (String): Sie können den Buildtyp angeben, für den Sie Tests ausgeführt haben, deren Ergebnisse Sie veröffentlichen möchten. Diese Eigenschaft entspricht der /flavor-Option des Befehls MSTest.exe. Weitere Informationen finden Sie unter Befehlszeilenoptionen zum Veröffentlichen von Testergebnissen.

  • Platform (String): Sie können die Plattform des Builds angeben, für den Sie Tests ausgeführt haben, deren Ergebnisse Sie veröffentlichen möchten. Diese Eigenschaft entspricht der /platform-Option des Befehls MSTest.exe. Weitere Informationen finden Sie unter Befehlszeilenoptionen zum Veröffentlichen von Testergebnissen.

  • TestConfigId (Int32): Sie können die ID einer vorhandenen Testverwaltungskonfiguration angeben, um diese dem Testlauf zuzuordnen, dessen Ergebnisse Sie veröffentlichen möchten. Diese Eigenschaft entspricht der /testconfigid-Option des Befehls MSTest.exe. Weitere Informationen erhalten Sie, indem Sie MSTest /? über die Visual Studio-Eingabeaufforderung ausführen.

  • TestConfigName (String): Sie können den Namen einer vorhandenen Testverwaltungskonfiguration angeben, um diese dem Testlauf zuzuordnen, dessen Ergebnisse Sie veröffentlichen möchten. Diese Eigenschaft entspricht der /testconfigname-Option des Befehls MSTest.exe. Weitere Informationen erhalten Sie, indem Sie MSTest /? über die Visual Studio-Eingabeaufforderung ausführen.

MSTest – Weitere Eigenschaften

  • CommandLineArguments (String): Weitere Informationen über zusätzliche Befehlszeilenoptionen finden Sie unter Befehlszeilenoptionen für MSTest.exe.

  • PathToResultsFilesRoot (String): Sie können den Stamm des Verzeichnispfads auf dem Build-Agent festlegen, wo MSTest.exe die Ergebnisdateien (TRX-Dateien) ablegt.

  • ToolPath (String): Sie können den Verzeichnispfad festlegen, wo sich die MSTest.exe-Version befindet, die Sie ausführen möchten. Wenn Sie keinen Pfad angeben, legt Team Foundation Build den Pfad automatisch auf Grundlage der Daten in den Testlisten und Testcontainern fest.

Zurück nach oben

Abrufen einer Liste der Tests, die vom Build betroffen sind (GetImpactedTests-Aktivität)

Verwenden Sie die GetImpactedTests-Aktivität, um Codeänderungen im aktuellen Build zu identifizieren und eine Liste der Tests zu erzeugen, die von diesen Änderungen betroffen sind. Die Aktivität schreibt die Liste mit den betroffenen Tests in das Data Warehouse, damit die Mitglieder des Testteams ermitteln können, welche Tests nach Abschluss des Builds ausgeführt werden müssen. Weitere Informationen über den Verwendungszweck dieser Daten für Ihr Team finden Sie unter Empfohlene auszuführende Tests, die von Codeänderungen betroffen sind.

Tipp

Diese Aktivität hat keine Auswirkungen auf abgegrenzte Eincheckbuilds oder private Builds.

Erforderliche Bedingungen

Die GetImpactedTests-Aktivität kann nur verwendet werden, wenn folgende Bedingungen erfüllt sind:

  • Die MSTest-Aktivität wurde mit einer Testeinstellungsdatei ausgeführt (angegeben in der TestSettings-Eigenschaft), die Testauswirkungsdaten sammelt. Sie können die Datei Traceandtestimpact.testsettings verwenden, die automatisch generiert wird, oder Sie können eine andere Testeinstellungsdatei verwenden, in der das Kontrollkästchen Testauswirkung aktiviert ist. Weitere Informationen finden Sie unter Gewusst wie: Sammeln von Daten, um zu überprüfen, welche Tests nach Codeänderungen ausgeführt werden sollen.

  • Die GetImpactedTests-Aktivität hat den vorherigen Build erfolgreich identifiziert. Weitere Informationen finden Sie im nächsten Abschnitt.

So identifiziert die GetImpactedTests-Aktivität den vorherigen Build

Die Ergebnisse der GetImpactedTests-Aktivität resultieren aus einem Vergleich des aktuellen Builds mit dem vorherigen Build. Die Aktivität identifiziert den vorherigen Build über den folgenden Prozess:

  1. Wenn Sie die BaselineBuildDropLocation-Eigenschaft festlegen, wird der Build, der diese Binärdateien generiert hat, als vorheriger Build identifiziert.

  2. Wenn Sie die BaselineBuildDropLocation-Eigenschaft nicht festlegen, ermittelt die Aktivität den vorherigen Build mittels einer Suche im Data Warehouse. Dabei wird nach dem aktuellen Build gesucht, der die folgenden Kriterien erfüllt:

    • Der Build weist denselben BuildDefinitionUri wie der aktuelle Build auf.

    • Status des Builds ist entweder Succeeded oder PartiallySucceeded.

    • Der Build verfügt über eine DropLocation.

    • Bei dem Build handelt es sich nicht um einen abgegrenzten Eincheckbuild oder um einen privaten Build.

GetImpactedTests-Result-Eigenschaften

  • CodeChanges (CodeChangeList): Gibt eine Liste der Änderungen zurück, die für jede Methode im Code seit dem vorherigen Build vorgenommen wurden. Die Methoden werden auf der Ebene der Microsoft Intermediate Language (MSIL) analysiert.

  • ImpactedTests (TestList): Gibt eine Liste der Tests zurück, die von den Codeänderungen seit dem vorherigen Build betroffen sind.

GetImpactedTests-Argumenteigenschaften

  • Sonstiges

    • Build: Sie müssen das IBuildDetail-Objekt des Builds bereitstellen. Sie können die GetBuildDetail-Aktivität verwenden, um einen Verweis auf dieses Objekt abzurufen.

  • Sonstiges

    • Assemblies (IEnumerable<String>): Sie müssen eine Liste der Assemblys angeben, die von dieser Aktivität überprüft werden sollen. In der Regel erstellen Sie diese Assemblys in diesem Build.

    • AssociatedChangesets (IList<T><Changeset>): Sie können die Changesets angeben, die Sie den Testauswirkungsergebnissen zuordnen möchten. In der Regel geben Sie die Changesets an, die Sie erstellen. Sie können einen Verweis auf diese Changesets über die AssociateChangesetsAndWorkItems-Aktivität abrufen.

    • BinariesRoot (String): Sie müssen den Pfad der Binärdateien angeben, von denen die Assemblys abhängig sind. Sie können diesen Wert mit der GetBuildDirectory-Aktivität abrufen.

    • Workspace (Workspace): Sie müssen einen Verweis auf den Arbeitsbereich des Builds bereitstellen. Sie können diesen Verweis über die Result-Eigenschaft der CreateWorkspace-Aktivität abrufen.

    • BaselineBuildDropLocation (String): Sie können den Pfad des Ablageordners mit dem abgeschlossenen Build angeben, der von der GetImpactedTests-Aktivität mit dem aktuellen Build verglichen werden soll. Wenn Sie diese Eigenschaft nicht festlegen, versucht die Aktivität den vorherigen Build über das Buildsystem abzufragen. Weitere Informationen finden Sie unter "So identifiziert die GetImpactedTests-Aktivität den vorherigen Build" weiter oben in diesem Abschnitt.

Zurück nach oben

Starten eines Prozesses (InvokeProcess-Aktivität)

Verwenden Sie die InvokeProcess-Aktivität, um auf dem Buildserver einen Prozess zu starten (ein Programm auszuführen). Diese Aktivität ist im Wesentlichen ein Wrapper für Start.

InvokeProcess Result (Int32)-Eigenschaft

Gibt den ExitCode des Prozesses zurück.

InvokeProcess-Argumenteigenschaften

  • FileName (String): Sie müssen FileName für den Prozess angeben, den Sie starten möchten (bzw. für das Programm, das Sie ausführen möchten). Beispiel: %ProgramFiles%\ContosoBuildUtils\MarkBins.exe.

  • Arguments (String): Sie können Befehlszeilenargumente (Arguments) angeben, die Sie an den Prozess übergeben möchten.

  • EnvironmentVariables (IDictionary<TKey, TValue><String,String>): Sie können zusätzliche Umgebungsvariablen (EnvironmentVariables) und deren Werte angeben.

  • OutputEncoding (Encoding): Sie können die Codierung zum Lesen der Ausgabe (StandardOutputEncoding) und Fehler(RedirectStandardError)-Streams angeben. In vielen Fällen ist der Standardwert der beste Wert für diese Eigenschaft:

    System.Text.Encoding.GetEncoding(System.Globalization.CultureInfo.InstalledUICulture.TextInfo.OEMCodePage)

  • WorkingDirectory (String): Sie können das Arbeitsverzeichnis (WorkingDirectory) angeben, in dem Sie den Prozess ausführen möchten.

    Beispielsweise können Sie das MarkBins.exe-Hilfsprogramm für die kompilierten Binärdateien ausführen. Um den Bereich einzugrenzen, in dem das Hilfsprogramm ausgeführt wird, können Sie GetBuildDirectory aufrufen und das Ergebnis in dieser Eigenschaft ablegen.

So zeigen Sie die Standardausgabe und die Fehlerausgabe von einem Prozess an

  1. Doppelklicken Sie in der InvokeProcess-Aktivität auf Zum Anzeigen doppelklicken.

  2. Ziehen Sie eine WriteBuildMessage-Aktivität aus der Toolbox, sodass die Aktivität unter Standardausgabe bearbeiten angezeigt wird, und legen Sie die WriteBuildMessage Message-Eigenschaft auf stdOutput fest.

  3. Ziehen Sie eine WriteBuildError-Aktivität aus der Toolbox, sodass die Aktivität unter Standardausgabe bearbeiten angezeigt wird, und legen Sie die WriteBuildMessage Message-Eigenschaft auf errOutput fest.

Arbeiten mit der Versionskontrolle

Sie können Team Foundation Build-Aktivitäten verwenden, um die folgenden Aufgaben der Versionskontrolle auszuführen:

  • Verknüpfen von Changesets und Arbeitsaufgaben mit dem Build

  • Einchecken abgegrenzter Änderungen

  • Prüfen von Eincheckrichtlinien

  • Bezeichnen von Dateien in der Versionskontrolle

Verknüpfen von Changesets und Arbeitsaufgaben mit dem Build (AssociateChangesetsAndWorkItems-Aktivität)

Verwenden Sie die AssociateChangesetsAndWorkItems-Aktivität, um jeden abgeschlossenen Build mit allen Code-Changesets und den ihnen zugeordneten Arbeitsaufgaben zu verknüpfen.

Für jede Builddefinition wird ein eigener Datensatz verwaltet, der die Changesets und Arbeitsaufgaben enthält, die dem nächsten abgeschlossenen Build zugeordnet werden sollen. Beispiel: Changeset 382 wird sowohl von Build A als auch von Build B erstellt. Build A wird in die Warteschlange gestellt und erfolgreich abgeschlossen, Build B wird ebenfalls in die Warteschlange gestellt, schlägt aber fehl. Changeset 382 wird jetzt mit dem erfolgreich abgeschlossenen Build A und mit dem fehlgeschlagenen Build B verknüpft. Anschließend wird Changeset 382 aber nicht mit dem nächsten abgeschlossenen Build von Build A verknüpft, sondern nur mit dem nächsten erfolgreich abgeschlossenen Build von Build B.

AssociateChangesetsAndWorkItems Result (IList<T><Changeset>)-Eigenschaft

Gibt die Changesets zurück, die dem Build zugeordnet wurden.

AssociateChangesetsAndWorkItems-Argumenteigenschaften

  • CurrentLabel (String): Lassen Sie diese Eigenschaft leer.

  • LastLabel (String): Lassen Sie diese Eigenschaft leer.

  • UpdateWorkItems (Boolean): Sie können den Wert dieser Eigenschaft auf True festlegen, wenn Sie das Fixed In-Feld der zugeordneten Arbeitsaufgaben mit der Buildnummer füllen möchten. Andernfalls wird der Wert auf False festgelegt.

Zurück nach oben

Einchecken abgegrenzter Änderungen (CheckInGatedChanges-Aktivität)

Verwenden Sie die CheckInGatedChanges-Aktivität, um die Codeänderungen, die einen abgegrenzten Eincheckbuild ausgelöst haben, in die Versionskontrolle einzuchecken. Diese Aktivität verknüpft den Build auch mit den Arbeitsaufgaben, die den Changesets zugeordnet sind.

Tipp

Um ordnungsgemäß zu funktionieren, muss diese Aktivität in der Vorlage hinter allen Implementierungen der MSBuild/MSTest-Aktivitäten eingefügt werden.

CheckInGatedChanges Result(Changeset) -Eigenschaft

Gibt das Changeset mit den Änderungen zurück, die eingecheckt werden.

CheckInGatedChanges-Argumenteigenschaften

  • IgnoreErrors (Boolean): Legen Sie diese Eigenschaft auf False fest, damit Dateien nur eingecheckt werden, wenn die beiden Eigenschaften TestStatus und CompilationStatus den Wert Succeeded aufweisen. Legen Sie diese Eigenschaft auf True fest, damit Dateien unabhängig von ihren Werten eingecheckt werden.

    Tipp

    Mit der SetBuildProperties-Aktivität können Sie die Eigenschaften CompilationStatus und TestStatus festlegen.

  • UpdateWorkItems (String): Legen Sie diesen Wert auf True fest, wenn Sie das Fixed In-Feld der zugeordneten Arbeitsaufgaben mit der Buildnummer füllen möchten. Legen Sie sie andernfalls auf False fest.

Zurück nach oben

Prüfen der Eincheckrichtlinien (EvaluateCheckInPolicies-Aktivität)

Verwenden Sie die EvaluateCheckInPolicies-Aktivität, um Eincheckrichtlinien auf dem Buildserver auszuführen. Die Aktivität wendet die Eincheckrichtlinien auf alle Ordner an, die auf der Registerkarte Arbeitsbereich der Builddefinition angegeben sind. Der Build schlägt fehl, wenn die Eincheckrichtlinien nicht erfüllt werden und die Ursache für den Build entweder CheckInShelveset (abgegrenzter Eincheckbuild) oder ValidateShelveset (privater Build) lautet.

Wichtig

Die Eincheckrichtlinien werden auf dem Buildserver, nicht auf dem Clientcomputer des Entwicklers ausgewertet.

Diese Aktivität dient in erster Linie der Durchsetzung strengerer Quality Gates, vorzugsweise in Kombination mit abgegrenzten Eincheckbuilds. Auf diese Weise wird der Benutzer daran gehindert, Eincheckrichtlinien zu umgehen. Die Aktivität ist für die folgenden Arten von Eincheckrichtlinien besonders hilfreich:

  • Die integrierte Work Items-Eincheckrichtlinie

  • Benutzerdefinierte Eincheckrichtlinien, die auf dem Buildserver ausgewertet werden

Diese Aktivität ist nicht geeignet für die Auswertung der integrierten Builds-, Code Analysis- oder Testing Policy-Richtlinien, weil diese Prozesse mit MSTest/MSBuild-Aktivitäten wesentlich effizienter direkt in einem Build ausgeführt werden können.

Weitere Informationen finden Sie in den folgenden Ressourcen:

EvaluateCheckInPolicies-Argumenteigenschaften

  • Workspace (Workspace): Sie müssen den Arbeitsbereich angeben, den Sie auswerten möchten. In den meisten Fällen sollten Sie diese Eigenschaft auf die Variable festlegen, die Sie in der Result-Eigenschaft der CreateWorkspace-Aktivität initialisieren. Wenn Sie einen Buildprozess erstellen, der auf DefaultTemplate.xaml basiert, sollten Sie die Workspace-Variable verwenden.

Zurück nach oben

Bezeichnen von Dateien in der Versionskontrolle

Sie können mit Team Foundation Build-Aktivitäten Dateien bezeichnen:

  • Bezeichnen des Build-Quellcodes

  • Bezeichnen von Dateien

Bezeichnen des Quellcodes, den Sie erstellen (LabelWorkspace-Aktivität)

Sie sollten Quellcodedateien in der Versionskontrolle bezeichnen, damit die Teammitglieder leichter ermitteln können, welche Version einer Datei im jeweils abgeschlossenen Build enthalten ist. Verwenden Sie die LabelWorkspace-Aktivität, um diesen Schritt in den Buildprozess mit aufzunehmen.

LabelWorkspace-Argumenteigenschaften

  • Name (String): Sie müssen den Namen der Bezeichnung angeben.

  • Child (LabelChildOption): Sie können angeben, wie Elemente verarbeitet werden sollen, die bereits über eine Bezeichnung verfügen, die mit der von Ihnen angegebenen Bezeichnung identisch ist. Diese Eigenschaft entspricht der /child-Option des Befehls tf label.

  • Workspace (Workspace): Sie müssen einen Verweis auf den Arbeitsbereich des Builds bereitstellen. In den meisten Fällen sollten Sie diese Eigenschaft auf die Variable festlegen, die Sie in der Result-Eigenschaft der CreateWorkspace-Aktivität initialisieren. Wenn Sie einen Buildprozess erstellen, der auf DefaultTemplate.xaml basiert, sollten Sie die Workspace-Variable verwenden.

  • Comment (String): Sie können einen Kommentar für die Bezeichnung angeben. Diese Eigenschaft entspricht der /comment-Option des Befehls tf label.

  • Scope (String): Sie können einen Bereich für die Bezeichnung angeben. Diese Eigenschaft entspricht dem @scope-Argument des Befehls tf label.

Weitere Informationen zu tf label-Parametern finden Sie unter Befehl Label (Team Foundation-Versionskontrolle).

Zurück nach oben

Bezeichnen von Dateien (LabelSources-Aktivität)

Verwenden Sie die LabelSources-Aktivität, um Dateien in der Versionskontrolle zu bezeichnen.

Tipp

Mit der LabelWorkspace-Aktivität können Sie Quellcodedateien noch effektiver bezeichnen.

LabelSources-Argumenteigenschaften

  • Items (IEnumerable<String>): Sie müssen die Elemente angeben, die Sie bezeichnen möchten. Jeder String entspricht einem itemspec-Argument des Befehls tf label.

  • Name (String): Sie müssen den Namen der Bezeichnung angeben.

  • Scope (String): Sie müssen einen Bereich für die Bezeichnung angeben. Diese Eigenschaft entspricht dem @scope-Argument des Befehls tf label.

  • Recursion (RecursionType): Sie können Microsoft.TeamFoundation.VersionControl.Client.RecursionType.Full angeben, wenn Sie alle Dateien in einer Verzeichnishierarchie bezeichnen wollen. Alternativ können Sie auch Microsoft.TeamFoundation.VersionControl.Client.RecursionType.OneLevel angeben.

  • Version (String): Sie müssen die Version der Elemente bereitstellen, die Sie bezeichnen möchten. Diese Eigenschaft entspricht der /version-Option des Befehls tf label.

  • Child (LabelChildOption): Sie können angeben, wie Elemente verarbeitet werden sollen, die bereits über eine Bezeichnung verfügen, die mit der von Ihnen angegebenen Bezeichnung identisch ist. Diese Eigenschaft entspricht der /child-Option des Befehls tf label.

  • Comment (String): Sie können einen Kommentar für die Bezeichnung angeben. Diese Eigenschaft entspricht der /comment-Option des Befehls tf label.

Weitere Informationen zu tf label-Parametern finden Sie unter Befehl Label (Team Foundation-Versionskontrolle).

Zurück nach oben

Arbeiten mit Arbeitsaufgaben

Mit den Team Foundation Build-Aktivitäten können Sie auf Arbeitsaufgaben zugreifen:

  • Verknüpfen von Changesets und Arbeitsaufgaben mit dem Build

  • Arbeitsaufgabe erstellen

Erstellen einer Arbeitsaufgabe (OpenWorkItem-Aktivität)

Verwenden Sie die OpenWorkItem-Aktivität, um eine Arbeitsaufgabe zu erstellen.

OpenWorkItem Result (WorkItem)- Eigenschaft

Gibt die neue Arbeitsaufgabe zurück.

OpenWorkItem-Argumenteigenschaften

  • AssignedTo (String): Sie müssen die Person angeben, der Sie die Arbeitsaufgabe zuweisen möchten.

  • Title (String): Sie müssen den Titel der Arbeitsaufgabe angeben.

  • Type (String): Sie müssen den Arbeitsaufgabentyp angeben. Typische Type-Werte sind: “Bug”, “Issue” und “Task”.

  • Comment (String): Sie können dem Verlauf der Arbeitsaufgabe einen Kommentar hinzufügen.

  • CustomFields (IDictionary<TKey, TValue><String,String>): Sie können die Werte von weiteren Feldern der Arbeitsaufgabe angeben.

Zurück nach oben

Arbeiten mit Symboldaten

Über die beiden Team Foundation Build-Aktivitäten IndexSources und PublishSymbols können Sie mit Symboldaten arbeiten.

Ein typisches Anwendungsbeispiel für diese Aktivität ist die Aktivierung des IntelliTrace-Debuggers. Wenn Sie den IntelliTrace-Debugger aktivieren möchten, müssen Sie zuerst die IndexSources-Aktivität aufrufen, um die Symboldaten vorzubereiten. Anschließend müssen Sie die PublishSymbols-Aktivität aufrufen, um die Daten in einem SymStore-Symbolspeicher zu veröffentlichen.

Weitere Informationen über das Debuggen mit IntelliTrace finden Sie unter Debuggen mit IntelliTrace.

Einbetten von Versionskontrollpfaden und Versionen in die Symboldaten der PDB-Dateien (IndexSources-Aktivität)

Verwenden Sie die IndexSources-Aktivität, um Versionskontrollpfade und Versionen in die Symboldaten der PDB-Dateien einzubetten.

IndexSources-Argumenteigenschaften

  • FileList (IEnumerable<String>): Sie müssen den vollständigen Pfad und den Namen jeder Symboldatei angeben. Sie können die FindMatchingFiles-Aktivität verwenden, um dieses Argument bereitzustellen.

    Sie können ** verwenden, um eine rekursive Suche anzugeben. Beispielsweise können Sie FindMatchingFiles mit dem folgenden Wert in der MatchPattern-Eigenschaft aufrufen: String.Format("{0}\**\*.pdb", BinariesDirectory).

Zurück nach oben

Veröffentlichen von Symbolen in einem SymStore-Symbolspeicher (PublishSymbols-Aktivität)

Verwenden Sie die PublishSymbols-Aktivität, um die Symboldaten in PDB-Dateien in einem SymStore-Symbolspeicher zu veröffentlichen. Diese Aktivität ist im Wesentlichen ein Wrapper für SymStore.exe. Weitere Informationen über SymStore-Symbolspeicher (und wie Sie solche Speicher vorbereiten) finden Sie unter Veröffentlichen von Symboldaten.

Wichtig

Daten können beschädigt werden, wenn parallele Builds versuchen, in derselben Symboldateifreigabe zu veröffentlichen. Um dieses Risiko zu verringern, sollten Sie diese Aktivität nur innerhalb einer SharedResourceScope-Aktivität aufrufen.

PublishSymbols Result (String)-Eigenschaft

Gibt die Transaktions-ID zurück, die SymStore.exe zurückgibt.

PublishSymbols-Argumenteigenschaften

  • FileList (IEnumerable<String>): Sie müssen den vollständigen Pfad und den Namen jeder Symboldatei angeben. Sie können die FindMatchingFiles-Aktivität verwenden, um dieses Argument bereitzustellen.

    Beispielsweise können Sie FindMatchingFiles mit dem folgenden Wert in der MatchPattern-Eigenschaft aufrufen: String.Format("{0}\**\*.pdb", BinariesDirectory).

  • StorePath (String): Sie müssen den UNC-Dateipfad zum Stammordner des SymStore-Symbolspeichers angeben.

  • CommandLineArguments (String): Weitere Informationen über zusätzliche Argumente, die Sie an SymStore.exe übergeben können, finden Sie unter SymStore-Befehlszeilenoptionen.

  • Comments (String): Sie können Transaktionskommentare angeben, die in der Transaktionsverlaufsdatei im Symbolspeicher aufgezeichnet werden. Diese Eigenschaft entspricht dem /c Comment-Parameter des Befehls SymStore.exe. Weitere Informationen finden Sie unter SymStore-Befehlszeilenoptionen.

  • ProductName (String): Sie können den Produktnamen angeben, der in der Transaktionsverlaufsdatei im Symbolspeicher aufgezeichnet wird. Beispielsweise können Sie diese Eigenschaft auf den Namen der Builddefinition (Name) festlegen, den Sie von der BuildDefinition-Eigenschaft erhalten haben (durch Aufruf von GetBuildDetail). Diese Eigenschaft entspricht dem /t Product-Parameter des Befehls SymStore.exe. Weitere Informationen finden Sie unter SymStore-Befehlszeilenoptionen.

  • StoreCompressed (Boolean): Sie können diesen Wert auf True festlegen, um Dateien im Symbolspeicher als komprimierte Dateien zu speichern. Andernfalls werden die Dateien in unkomprimierter Form gespeichert. Diese Eigenschaft entspricht dem /compress-Parameter des Befehls SymStore.exe. Weitere Informationen finden Sie unter SymStore-Befehlszeilenoptionen.

  • Version (String): Beispielsweise können Sie diese Eigenschaft auf die Buildnummer (BuildNumber) festlegen, die Sie durch einen Aufruf von GetBuildDetail erhalten. Diese Eigenschaft entspricht dem /v Version-Parameter des Befehls SymStore.exe. Weitere Informationen finden Sie unter SymStore-Befehlszeilenoptionen.

Zurück nach oben

Abrufen von Verweisen auf nützliche Objekte

Sie können mit Team Foundation Build-Aktivitäten Verweise auf nützliche Objekte abrufen.

Abrufen eines Verweises auf ein Objekt für eine Teamprojektsammlung (GetTeamProjectCollection-Aktivität)

Verwenden Sie die GetTeamProjectCollection-Aktivität, um über die Result-Eigenschaft einen Verweis auf ein TfsTeamProjectCollection-Objekt abzurufen. Dieses Startobjekt ist wichtig; beispielsweise können Sie es zum Herstellen einer Verbindung mit einem Anwendungsebenenserver für Team Foundation verwenden.

Abrufen eines Verweises auf das IBuildAgent-Objekt (GetBuildAgent-Aktivität)

Verwenden Sie die GetBuildAgent-Aktivität, um über die Result-Eigenschaft einen Verweis auf das IBuildAgent-Objekt abzurufen. Sie können diese Aktivität nur innerhalb einer AgentScope-Aktivität verwenden.

Abrufen eines Verweises auf das IBuildDetail-Objekt (GetBuildDetail-Aktivität)

Verwenden Sie die GetBuildDetail-Aktivität, um über die Result-Eigenschaft einen Verweis auf das IBuildDetail-Objekt abzurufen. Sie können mit diesem Objekt Daten über den aktuellen Build abrufen (und in Einzelfällen auch festlegen).

Zurück nach oben

Abrufen eines Verweises auf das BuildEnvironment-Objekt (GetBuildEnvironment-Aktivität)

Verwenden Sie die GetBuildEnvironment-Aktivität, um über die Result-Eigenschaft einen Verweis auf das BuildEnvironment-Objekt abzurufen. Sie verwenden diese Eigenschaft i. d. R. dazu, folgende Aufgaben auszuführen:

  • Verwenden Sie das Environment-Objekt, um zu bestimmen, ob das aktuelle Segment des Workflows auf dem Buildcontroller oder auf dem Build-Agent ausgeführt wird.

  • Verwenden Sie das CustomAssemblyPath-Objekt verwendet, um den Pfad zu den Assemblys abzurufen, die die benutzerdefinierten Aktivitäten auf dem Build-Agent enthalten.

Zurück nach oben

Aktivitäten, die nicht zur Wiederverwendung in einem benutzerdefinierten Buildprozess vorgesehen sind

Einige Aktivitäten sind nicht für die Verwendung in einem benutzerdefinierten Buildprozess bestimmt.

TfsBuild-Aktivität

Ignorieren Sie diese Aktivität. Sie wird nur in UpgradeTemplate.xaml verwendet. Die Aktivität ist nicht für die Wiederverwendung in einem benutzerdefinierten Buildprozess bestimmt.

CreateWorkspace-Aktivität

Es kommt sehr selten vor, dass Sie eine Instanz der CreateWorkspace-Aktivität erstellen oder ändern müssen. Wenn Sie einen Buildprozess entwerfen, der einen oder mehrere zusätzliche Arbeitsbereiche erfordert, müssen Sie hierzu eine benutzerdefinierte Aktivität erstellen.

Andere Workspace-Aktivitäten

Die Buildprozessvorlage verwendet diese Aktivitäten ggf. auf dieselbe Weise wie DefaultTemplatate.xaml. Wenn Sie nicht gerade eine benutzerdefinierte Aktivität zum Erstellen eines Arbeitsbereichs entwickeln, kommt es sehr selten vor, dass Sie eine Instanz eines Arbeitsbereichs in der benutzerdefinierten Buildprozessvorlage erstellen oder ändern müssen.

DeleteWorkspace

Zurück nach oben

GetWorkspace

Zurück nach oben

RevertWorkspace

Zurück nach oben

SyncWorkspace

Zurück nach oben

Siehe auch

Aufgaben

Erstellen und Verwenden von Build-Agents

Anzeigen des Fensters "Buildergebnisse"

Konzepte

Definieren eines Builds mithilfe der Standardvorlage

Weitere Ressourcen

Visual Studio 2010 Workflow Designer

Windows Workflow Foundation

Erstellen und Verwenden eines Buildcontrollers

MSBuild-Referenz