Exemplarische Vorgehensweise: Anpassen von Team Foundation Build mithilfe einer benutzerdefinierten Aufgabe
Sie können Team Foundation Build erweitern, indem Sie eigene benutzerdefinierte Aufgaben erstellen und sie während eines Builds ausführen. In diesem Thema werden die Schritte erläutert, die zum Erweitern eines Buildtyps mit einer benutzerdefinierten Aufgabe erforderlich sind.
Erstellen eines Buildtyps
Verwenden Sie den Assistenten zum Erstellen neuer Teambuildtypen, um einen neuen Buildtyp zu erstellen. Dadurch wird die Datei TfsBuild.proj erstellt und in die Quellcodeverwaltung eingecheckt. Sie bearbeiten diese Datei, um den Buildtyp anzupassen. Weitere Informationen zum Erstellen von Buildtypen finden Sie unter Gewusst wie: Erstellen eines neuen Buildtyps.
Erstellen von benutzerdefinierten Aufgaben
Mit Aufgaben wird der Code bereitgestellt, der während des Buildprozesse ausgeführt wird. Sie sind in den Target-Elementen der MSBuild-Projektdateien enthalten. MSBuild ist das Modul für Team Foundation Build, und die benutzerdefinierten Aufgaben müssen ein Format haben, dass von MSBuild verarbeitet werden kann. Jede Aufgabe muss als .NET-Klasse implementiert werden, durch die die in der Assembly Microsoft.Build.Framework.dll definierte ITask-Schnittstelle eingerichtet wird.
Es gibt zwei Vorgehensweisen für das Implementieren einer Aufgabe:
Direktes Implementieren der ITask-Schnittstelle
Ableiten der Klasse von der Task-Hilfsklasse, die in der Assembly Microsoft.Build.Utilities.dll definiert ist. Task implementiert ITask und stellt Standardimplementierungen einiger ITask-Member bereit.
In beiden Fällen müssen Sie der Klasse eine Methode mit dem Namen Execute hinzufügen. Diese Methode wird aufgerufen, wenn die Aufgabe ausgeführt wird. Diese Methode enthält keine Parameter und gibt einen Boolean-Wert zurück: true bei erfolgreicher und false bei nicht erfolgreicher Ausführung der Aufgabe. Im folgenden Beispiel wird eine Aufgabe veranschaulicht, die keine Aktionen ausführt und true zurückgibt.
using System;
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;
namespace MyTasks
{
public class SimpleTask : Task
{
public override bool Execute()
{
return true;
}
}
}
Aufgaben können auch Parameter akzeptieren, Ereignisse auslösen und Ausgaben protokollieren. Weitere Informationen finden Sie unter MSBuild-Aufgaben und Übersicht über MSBuild.
Auschecken von TfsBuild.proj
Nachdem Sie die Aufgabe geschrieben haben, müssen Sie sie registrieren und in einem der Ziele aufrufen, damit der Aufgabencode am gewünschten Punkt im Buildvorgang ausgeführt wird. Sie finden die Datei TfsBuild.proj im Ordner $/EigenesTeamprojekt/TeamBuildTypes/EigenerBuildname in der Visual Studio Team System-Quellcodeverwaltung, wobei EigenesTeamprojekt für den Namen Ihres Teamprojekts steht und der Stammknoten aller Ihrer Teamprojektquellen ist. EigenerBuildname steht für den Namen, den Sie Ihrem Buildtyp bei der Erstellung mit dem Assistenten zum Erstellen neuer Teambuildtypen zugewiesen haben. Jeder Buildtyp ist in einem Ordner im Ordner TeamBuildTypes unter dem Stammknoten des Teamprojekts gespeichert.
Hinweis
Bearbeiten Sie nicht die Datei Microsoft.TeamFoundation.Build.targets, da die Anpassungen dann für alle Builds auf diesem Computer gelten.
Informationen über das Auschecken von Dateien finden Sie unter Arbeiten mit der Team Foundation-Quellcodeverwaltung.
Registrieren der Aufgabe
Nachdem Sie die Aufgabe erstellt haben, müssen Sie sie registrieren, indem Sie sie in einem UsingTask-Element in der Datei TfsBuild.proj angeben. Das UsingTask-Element ordnet die Aufgabe der Assembly zu, die die Implementierung der Aufgabe enthält. Weitere Informationen finden Sie unter UsingTask-Element (MSBuild).
So registrieren Sie eine benutzerdefinierte Aufgabe
Öffnen Sie die Datei TfsBuild.proj.
Fügen Sie der Datei ein UsingTask-Element hinzu, und geben Sie die Details der Aufgabe an. Beispiel:
<UsingTask TaskName="MyTasks.SimpleTask" AssemblyName="MyAssembly.Build.Tasks"/>– oder –
<UsingTask TaskName="MyTasks.SimpleTask" AssemblyFile="MyAssembly.Build.Tasks.dll"/>– oder –
<UsingTask TaskName="MyTasks.SimpleTask" AssemblyFile="c:\somediskpath\MyAssembly.Build.Tasks.dll"/>Speichern Sie die Datei.
Ausführen der benutzerdefinierten Aufgabe
Nach dem Erstellen und Registrieren der Aufgabe müssen Sie den Punkt im Buildprozess angeben, zu dem die Aufgabe ausgeführt werden soll.
So führen Sie eine Aufgabe aus
Legen Sie fest, wo im Buildprozess die benutzerdefinierte Aufgabe ausgeführt werden soll. Weitere Informationen zum Erweitern des Buildprozesses finden Sie unter Team Foundation Build-Konfigurationsdateien.
Öffnen Sie TfsBuild.proj, und fügen Sie das Target-Element hinzu, dass Sie oben ausgewählt haben.
Fügen Sie das Aufgabenelement hinzu, um die Aufgabe im Target-Element auszuführen. Mit dem folgenden XML-Code in TfsBuild.proj beispielsweise wird die
SimpleTask-Aufgabe imBeforeGet-Ziel ausgeführt, das direkt vor demGet-Ziel ausgeführt wird.<Target Name="BeforeGet"> <SimpleTask /> </Target>Speichern Sie die Datei.
Einchecken der Dateien
Sie müssen die Datei TfsBuild.proj einchecken, damit die Änderungen wirksam werden. Team Foundation Build kopiert diese Datei aus der Quellcodeverwaltung auf den Buildcomputer, sodass sich die an Ihrer lokalen Kopie vorgenommenen Änderungen nicht auf das Build auswirken. Weitere Informationen zum Einchecken von Dateien in die Quellcodeverwaltung finden Sie unter Gewusst wie: Einchecken von ausstehenden Änderungen.
Wenn Sie möchten, dass Team Foundation Build die DLL der Aufgabe auf den Buildcomputer kopiert, müssen Sie die DLL unter dem Teamprojektknoten der Quellcodeverwaltung hinzufügen.
Beispielaufgabe
In diesem Beispiel wird eine benutzerdefinierte Aufgabe erstellt, die den Buildtyp MyBuildType durch Protokollieren der Größe der vom Build erstellten Dateien erweitert. Das Beispiel besteht aus zwei Teilen:
Aufgabencode
Datei TfsBuild.proj.
Die protokollierten Informationen dieser Aufgabe können in der Buildprotokolldatei Buildlog.log im Buildablageordner eingesehen werden. Das Buildprotokoll enthält z. B. Informationen ähnlich den Folgenden:
Die Gesamtgröße im Verzeichnis d:\BuildDir\MyTeamProj\MyBuildType\sources\..\Binaries\Release beträgt 9216 Bytes.
C#-Aufgabencode
Das untenstehende Beispiel enthält den Code, mit dem die Gesamtgröße aller Binärdateien durch Summieren der Größe der Dateien im Ordner Binaries berechnet wird.
Hinweis
Alle während eines Builds generierten Binärdateien befinden sich im Ordner Binaries auf dem Buildcomputer.
Damit diese Aufgabe in einem Build verwendet werden kann, muss die kompilierte DLL unter dem Teamprojektordner in die Quellcodeverwaltung eingecheckt werden. Dies garantiert, dass die Datei während eines Builds auf den Buildcomputer kopiert wird.
Mit dem untenstehenden Code wird die Größe der Binärdateien im Ordner Binaries des Buildverzeichnisses berechnet. Die Projektmappenstammeigenschaft wird vom Team Foundation Build-Skript an diese Aufgabe übergeben.
using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;
using System.Diagnostics;
using System.IO;
namespace BuildTask
{
public class BinSize : Task
{
private string sourceDir;
[Required]
public string SourceDir
{
get { return sourceDir; }
set { sourceDir = value; }
}
public override bool Execute()
{
string szDir = sourceDir + "\\..\\Binaries";
ProcessDirectory(szDir);
return true;
}
private void ProcessDirectory(string targetDirectory)
{
// Process the list of files found in the directory.
string[] fileEntries = Directory.GetFiles(targetDirectory, "*.*");
if (fileEntries.Length > 0)
{
dwSize = 0;
szCurrDir = targetDirectory;
foreach (string fileName in fileEntries)
ProcessFile(fileName);
////////////////////////////////////////////////////////////////////////
// This log message would just print out a line in the build log file.
// You need to add code to do what you need to do with this data. e.g.
// publishing it into the warehouse for reporting.
///////////////////////////////////////////////////////////////////////
Log.LogMessage("The total size of is {0} bytes in {1} dir",
dwSize, targetDirectory);
}
// Recurse into subdirectories of this directory.
string[] subdirectoryEntries = Directory.GetDirectories(targetDirectory);
foreach (string subdirectory in subdirectoryEntries)
ProcessDirectory(subdirectory);
}
private void ProcessFile(string path)
{
FileInfo fi = new FileInfo(path);
dwSize = dwSize + fi.Length;
}
private long dwSize;
private string szCurrDir;
}
}
Datei TfsBuild.proj
Nachdem die Aufgabe kompiliert und in die Quellcodeverwaltung eingecheckt wurde, muss sie aus der Datei TfsBuild.proj aufgerufen werden. In diesem Beispiel sollte die Aufgabe aufgerufen werden, nachdem alle Dateien kompiliert und alle Binärdateien in das Verzeichnis Binaries kopiert wurden. Daher sollte die Aufgabe im BeforeDropBuild-Ziel ausgeführt werden. Weitere Informationen über die erweiterbaren Ziele in TfsBuild.proj finden Sie unter Team Foundation Build-Konfigurationsdateien.
Das folgende Beispiel enthält den Code in der geänderten Datei TfsBuild.proj. Der XML-Code in diesem Beispiel wurde fast vollständig vom Assistenten zum Erstellen neuer Teambuildtypen generiert, mit Ausnahme des UsingTask-Elements und des Target-Elements, die sich am Ende der Datei befinden.
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="DesktopBuild" xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
<!-- TO EDIT BUILD TYPE DEFINITION
To edit the build type, you will need to edit this file which was generated
by the Create New Build Type wizard. This file is under source control and
needs to be checked out before making any changes.
The file is available at -
$/{TeamProjectName}/TeamBuildTypes/{BuildTypeName}
where you will need to replace TeamProjectName and BuildTypeName with your
Team Project and Build Type name that you created
Checkout the file
1. Open Source Control Explorer by selecting View -> Other Windows -> Source Control Explorer
2. Ensure that your current workspace has a mapping for the $/{TeamProjectName}/TeamBuildTypes folder and
that you have done a "Get Latest Version" on that folder
3. Browse through the folders to {TeamProjectName}->TeamBuildTypes->{BuildTypeName} folder
4. From the list of files available in this folder, right click on TfsBuild.Proj. Select 'Check Out For Edit...'
Make the required changes to the file and save
Checkin the file
1. Right click on the TfsBuild.Proj file selected in Step 3 above and select 'Checkin Pending Changes'
2. Use the pending checkin dialog to save your changes to the source control
Once the file is checked in with the modifications, all future builds using
this build type will use the modified settings
-->
<!-- Do not edit this -->
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v8.0\TeamBuild\Microsoft.TeamFoundation.Build.targets" />
<ProjectExtensions>
<!-- DESCRIPTION
The description is associated with a build type. Edit the value for making changes.
-->
<Description>
</Description>
<!-- BUILD MACHINE
Name of the machine which will be used to build the solutions selected.
-->
<BuildMachine>MyBuildMachine</BuildMachine>
</ProjectExtensions>
<PropertyGroup>
<!-- TEAM PROJECT
The team project which will be built using this build type.
-->
<TeamProject>MyTeamProject</TeamProject>
<!-- BUILD DIRECTORY
The directory on the build machine that will be used to build the
selected solutions. The directory must be a local path on the build
machine (for example, c:\build).
-->
<BuildDirectoryPath>d:\build</BuildDirectoryPath>
<!-- DROP LOCATION
The location to drop (copy) the built binaries and the log files after
the build is complete. This location must be a valid UNC path of the
form \\Server\Share. The build machine service account and application
tier account must have read write permission on this share.
-->
<DropLocation>\\MyDropServer\drops</DropLocation>
<!-- TESTING
Set this flag to enable/disable running tests as a post build step.
-->
<RunTest>true</RunTest>
<!-- WorkItemFieldValues
Add or edit key value pairs to set values for fields in the work item created
during the build process. Please make sure the field names are valid
for the work item type being used.
-->
<WorkItemFieldValues>Priority=1;Severity=1</WorkItemFieldValues>
<!-- CODE ANALYSIS
To change CodeAnalysis behavior, edit this value. Valid values for this
can be Default, Always, or Never.
Default - To perform code analysis according to individual project settings.
Always - To always perform code analysis irrespective of project settings.
Never - To never perform code analysis irrespective of project settings.
-->
<RunCodeAnalysis>Default</RunCodeAnalysis>
<!-- UPDATE ASSOCIATED WORK ITEMS
Set this flag to enable/disable updating associated work items on a successful build
-->
<UpdateAssociatedWorkItems>true</UpdateAssociatedWorkItems>
</PropertyGroup>
<ItemGroup>
<!-- SOLUTIONS
The path of the solutions to build. To add or delete solutions, edit this
value. For example, to add a solution MySolution.sln, add following line -
<SolutionToBuild Include="$(SolutionRoot)\path\MySolution.sln" />
To change the order in which the solutions are built, modify the order in
which the solutions appear below.
-->
<SolutionToBuild Include="$(SolutionRoot)\ConsoleApplication7\ConsoleApplication7.sln" />
</ItemGroup>
<ItemGroup>
<!-- CONFIGURATIONS
The list of configurations to build. To add or delete configurations, edit
this value. For example, to add a new configuration, add the following lines -
<ConfigurationToBuild Include="Debug|x86">
<FlavorToBuild>Debug</FlavorToBuild>
<PlatformToBuild>x86</PlatformToBuild>
</ConfigurationToBuild>
The Include attribute value should be unique for each ConfigurationToBuild node.
-->
<ConfigurationToBuild Include="Release|Any CPU">
<FlavorToBuild>Release</FlavorToBuild>
<PlatformToBuild>Any CPU</PlatformToBuild>
</ConfigurationToBuild>
<ConfigurationToBuild Include="Debug|Any CPU">
<FlavorToBuild>Debug</FlavorToBuild>
<PlatformToBuild>Any CPU</PlatformToBuild>
</ConfigurationToBuild>
<ConfigurationToBuild Include="Debug|x86">
<FlavorToBuild>Debug</FlavorToBuild>
<PlatformToBuild>x86</PlatformToBuild>
</ConfigurationToBuild>
<ConfigurationToBuild Include="Release|x86">
<FlavorToBuild>Release</FlavorToBuild>
<PlatformToBuild>x86</PlatformToBuild>
</ConfigurationToBuild>
</ItemGroup>
<ItemGroup>
<!-- TEST ARGUMENTS
If the RunTest is set to true then the following test arguments will be
used to run tests.
To add or delete new testlist or to choose a metadata file (.vsmdi) file, edit this value.
For example, to run BVT1 and BVT2 type tests mentioned in the Helloworld.vsmdi file, add the following -
<MetaDataFile Include="$(SolutionRoot)\HelloWorld\HelloWorld.vsmdi">
<TestList>BVT1;BVT2</TestList>
</MetaDataFile>
Where BVT1 and BVT2 are valid test types defined in the HelloWorld.vsmdi file.
MetaDataFile - Full path to test metadata file.
TestList - The test list in the selected metadata file to run.
Please note that you must specify the .vsmdi file relative to $(SolutionRoot)
-->
<MetaDataFile Include="$(SolutionRoot)\ConsoleApplication7\ConsoleApplication7.vsmdi">
<TestList>P1 Tests;P2 Tests</TestList>
</MetaDataFile>
</ItemGroup>
<ItemGroup>
<!-- ADDITIONAL REFERENCE PATH
The list of additional reference paths to use while resolving references.
For example,
<AdditionalReferencePath Include="C:\MyFolder\" />
<AdditionalReferencePath Include="C:\MyFolder2\" />
-->
</ItemGroup>
<UsingTask TaskName="BuildTask.BinSize" AssemblyFile="$(SolutionRoot)\\tools\\BuildTask.dll" />
<Target Name="BeforeDropBuild">
<BinSize SourceDir="$(SolutionRoot)" />
</Target>
</Project>
Sicherheit
Zum Abschließen dieser exemplarischen Vorgehensweise muss die Build verwalten-Berechtigung auf Zulassen festgelegt sein. Weitere Informationen finden Sie unter Team Foundation Server-Berechtigungen.
Siehe auch
Aufgaben
Gewusst wie: Schreiben von Aufgaben