Einrichten der Paketwiederherstellung mit Team Foundation Build

Dieser Artikel bietet eine ausführliche Schritt-für-Schritt-Anleitung zur Wiederherstellung von Paketen als Teil des Team Services Build sowohl für Git-Repositorys als auch für Team Services Version Control.

Obwohl diese exemplarische Vorgehensweise für das Szenario der Verwendung von Visual Studio Team Services spezifisch ist, gelten die Konzepte auch für andere Versionssteuerungs- und Buildsysteme.

Gilt für:

• Benutzerdefinierte MSBuild-Projekte, die auf einer beliebigen Version von TFS ausgeführt werden
• Team Foundation Server 2012 oder früher
• Benutzerdefinierte Team Foundation-Build-Prozessvorlagen, die zu TFS 2013 oder höher migriert wurden
• Erstellen von Prozessvorlagen mit entfernter Nuget-Wiederherstellungsfunktion

Wenn Sie Visual Studio Team Services oder Team Foundation Server 2013 mit seinen Buildprozessvorlagen verwenden, erfolgt die automatische Paketwiederherstellung als Teil des Buildprozesses.

Der allgemeine Ansatz

Ein Vorteil der Verwendung von NuGet besteht darin, dass Sie es verwenden können, um das Einchecken von Binärdateien in Ihrem Versionssteuerungssystem zu vermeiden.

Dies ist besonders interessant, wenn Sie ein verteiltes Versionssteuerungssystem wie Git verwenden, da Entwickler das gesamte Repository, einschließlich des vollständigen Verlaufs, klonen müssen, bevor sie lokal arbeiten können. Das Einchecken von Binärdateien kann zu einer erheblichen Aufblähung des Repositorys führen, da Binärdateien normalerweise ohne Deltakomprimierung gespeichert werden.

NuGet hat das Wiederherstellen von Paketen im Rahmen des Builds seit langem unterstützt. Die vorherige Implementierung hatte ein Hühner-und-Ei-Problem für Pakete, die den Buildprozess erweitern möchten, da NuGet Pakete beim Erstellen des Projekts wiederhergestellt hat. MSBuild lässt jedoch das Erweitern des Builds während des Builds nicht zu; man könnte argumentieren, dass dies ein Problem in MSBuild ist, aber ich würde argumentieren, dass dies ein inhärentes Problem ist. Je nachdem, welcher Aspekt Sie verlängern müssen, ist es möglicherweise zu spät, um sich zu registrieren, bis das Paket wiederhergestellt wird.

Die Heilung für dieses Problem stellt sicher, dass Pakete als erster Schritt im Buildprozess wiederhergestellt werden:

nuget restore path\to\solution.sln

Wenn Ihr Buildprozess Pakete vor dem Erstellen des Codes wiederherstellt, müssen Sie keine Dateien einchecken .targets.

Hinweis

Pakete müssen erstellt werden, um das Laden in Visual Studio zuzulassen. Andernfalls möchten Sie möglicherweise immer noch Dateien im .targets einchecken, damit andere Entwickler die Lösung einfach öffnen können, ohne zuerst Pakete wiederherstellen zu müssen.

Das folgende Demoprojekt zeigt, wie Sie den Build so einrichten, dass die packages Ordner und .targets Dateien nicht eingecheckt werden müssen. Außerdem wird gezeigt, wie Sie einen automatisierten Build für den Team Foundation-Dienst für dieses Beispielprojekt einrichten.

Repositorystruktur

Unser Demoprojekt ist ein einfaches Befehlszeilentool, das das Befehlszeilenargument verwendet, um Bing abzufragen. Es zielt auf .NET Framework 4 ab und verwendet viele der BCL-Pakete (Microsoft.Net.Http, Microsoft.Bcl, Microsoft.Bcl.Async und Microsoft.Bcl.Build).

Die Struktur des Repositorys sieht wie folgt aus:

<Project>
    │   .gitignore
    │   .tfignore
    │   build.proj
    │
    ├───src
    │   │   BingSearcher.sln
    │   │
    │   └───BingSearcher
    │       │   App.config
    │       │   BingSearcher.csproj
    │       │   packages.config
    │       │   Program.cs
    │       │
    │       └───Properties
    │               AssemblyInfo.cs
    │
    └───tools
        └───NuGet
                nuget.exe

Sie können sehen, dass wir weder den packages Ordner noch irgendwelche .targets Dateien eingecheckt haben.

Wir haben das nuget.exe jedoch eingecheckt, da es während des Builds benötigt wird. Gemäß weit verbreiteten Konventionen haben wir es in einem freigegebenen tools Ordner gespeichert.

Der Quellcode befindet sich unter dem src Ordner. Obwohl unsere Demo nur eine einzige Lösung verwendet, können Sie sich leicht vorstellen, dass dieser Ordner mehr als eine Lösung enthält.

Dateien ignorieren

Hinweis

Es gibt derzeit ein [known bug in the NuGet client](https://nuget.codeplex.com/workitem/4072), das bewirkt, dass der Client den packages Ordner weiterhin zur Versionsverwaltung hinzufügt. Eine Problemumgehung besteht darin, die Integration der Quellcodeverwaltung zu deaktivieren. Um dies zu tun, benötigen Sie eine Nuget.Config Datei im .nuget Ordner, der parallel zu Ihrer Lösung liegt. Wenn dieser Ordner noch nicht vorhanden ist, müssen Sie ihn erstellen. Fügen Sie in Nuget.Config den folgenden Inhalt hinzu:

<configuration>
    <solution>
        <add key="disableSourceControlIntegration" value="true" />
    </solution>
</configuration>

Um mit der Versionsverwaltung zu kommunizieren, dass wir nicht beabsichtigen, die Paketordner einzuchecken , haben wir auch Dateien für Git (.gitignore) und TF-Versionssteuerung (.tfignore) ignoriert. Diese Dateien beschreiben Muster von Dateien, die Sie nicht einchecken möchten.

Die .gitignore Datei sieht wie folgt aus:

syntax: glob
*.user
*.suo
bin
obj
packages
*.nupkg
project.lock.json
project.assets.json

Die .gitignore Datei ist ziemlich leistungsfähig. Wenn Sie z. B. den Inhalt des packages Ordners im Allgemeinen nicht einchecken möchten, aber mit vorherigen Anleitungen zum Einchecken der .targets Dateien fortfahren möchten, könnten Sie stattdessen die folgende Regel haben:

packages
!packages/**/*.targets

Dadurch werden alle packages Ordner ausgeschlossen, .targets aber die darin enthaltenen Dateien wieder eingeschlossen. Übrigens finden Sie hier eine Vorlage für .gitignore Dateien, die speziell auf die Anforderungen von Visual Studio-Entwicklern zugeschnitten sind.

TF-Versionssteuerung unterstützt einen sehr ähnlichen Mechanismus über die TFIGNORE-Datei . Die Syntax ist praktisch identisch:

*.user
*.suo
bin
obj
packages
*.nupkg
project.lock.json
project.assets.json

build.proj

Für unsere Demo halten wir den Buildprozess relativ einfach. Wir erstellen ein MSBuild-Projekt, das alle Lösungen erstellt und gleichzeitig sicherstellt, dass Pakete wiederhergestellt werden, bevor Sie die Lösungen erstellen.

Dieses Projekt wird die drei herkömmlichen Ziele CleanBuild und Rebuild ein neues Ziel aufweisenRestorePackages.

• Die beiden Ziele Build und Rebuild hängen von RestorePackages ab. Dadurch wird sichergestellt, dass Sie sowohl Build und Rebuild ausführen, als auch darauf vertrauen können, dass Pakete wiederhergestellt werden.
• Clean, Build und Rebuild rufen das entsprechende MSBuild-Ziel für alle Lösungsdateien auf.
• Das RestorePackages Ziel ruft für jede Lösungsdatei nuget.exe auf. Dazu wird die Batchfunktion von MSBuild verwendet.

Das Ergebnis sieht wie folgt aus:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0"
            DefaultTargets="Build"
            xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

    <PropertyGroup>
    <OutDir Condition=" '$(OutDir)'=='' ">$(MSBuildThisFileDirectory)bin\</OutDir>
    <Configuration Condition=" '$(Configuration)'=='' ">Release</Configuration>
    <SourceHome Condition=" '$(SourceHome)'=='' ">$(MSBuildThisFileDirectory)src\</SourceHome>
    <ToolsHome Condition=" '$(ToolsHome)'=='' ">$(MSBuildThisFileDirectory)tools\</ToolsHome>
    </PropertyGroup>

    <ItemGroup>
    <Solution Include="$(SourceHome)*.sln">
        <AdditionalProperties>OutDir=$(OutDir);Configuration=$(Configuration)</AdditionalProperties>
    </Solution>
    </ItemGroup>

    <Target Name="RestorePackages">
    <Exec Command="&quot;$(ToolsHome)NuGet\nuget.exe&quot; restore &quot;%(Solution.Identity)&quot;" />
    </Target>

    <Target Name="Clean">
    <MSBuild Targets="Clean"
                Projects="@(Solution)" />
    </Target>

    <Target Name="Build" DependsOnTargets="RestorePackages">
    <MSBuild Targets="Build"
                Projects="@(Solution)" />
    </Target>

    <Target Name="Rebuild" DependsOnTargets="RestorePackages">
    <MSBuild Targets="Rebuild"
                Projects="@(Solution)" />
    </Target>
</Project>

Konfigurieren des Teambuilds

TeamBuild bietet verschiedene Prozessvorlagen. Für diese Demonstration verwenden wir den Team Foundation-Dienst. Lokale Installationen von TFS sind jedoch sehr ähnlich.

Git und TF Version Control verfügen über unterschiedliche Teambuildvorlagen, sodass die folgenden Schritte abhängig davon variieren, welches Versionssteuerungssystem Sie verwenden. In beiden Fällen müssen Sie nur das Build.proj als Projekt auswählen, das Sie erstellen möchten.

Sehen wir uns zunächst die Prozessvorlage für Git an. In der git-basierten Vorlage wird der Build über die Eigenschaft Solution to buildausgewählt:

Bitte beachten Sie, dass diese Eigenschaft ein Speicherort in Ihrem Repository ist. Da sich unser build.proj in der Wurzel befindet, haben wir einfach build.proj verwendet. Wenn Sie die Builddatei in einem Ordner namens tools ablegen, lautet der Wert tools\build.proj.

In der TF-Versionssteuerungsvorlage wird das Projekt über die Eigenschaft Projectsausgewählt:

Im Gegensatz zur Git-basierten Vorlage unterstützt das TF-Versionskontrollsystem Auswahlwerkzeuge, wie etwa die Schaltfläche mit den drei Punkten auf der rechten Seite. Um Tippfehler zu vermeiden, empfehlen wir Ihnen, sie zum Auswählen des Projekts zu verwenden.