Verwenden des .NET SDK in CI-Umgebungen (Continuous Integration)

In diesem Artikel wird beschrieben, wie Sie das .NET SDK und die zugehörigen Tools auf einem Buildserver verwenden. Das .NET-Toolset funktioniert sowohl interaktiv, wobei ein Entwickler Befehle an einer Eingabeaufforderung eingibt, als auch automatisch, wenn ein CI-Server (Continuous Integration) ein Buildskript ausführt. Die Befehle, Optionen, Eingaben und Ausgaben sind dieselben, Sie stellen lediglich eine Methode zum Download der Tools und ein System zur Erstellung Ihrer App bereit. Dieser Artikel konzentriert sich auf Szenarien der Toolakquisition für CI mit Empfehlungen zum Entwerfen und Strukturieren Ihrer Buildskripts.

Installationsoptionen für CI-Buildserver

Wenn Sie GitHub verwenden, ist die Installation einfach. Sie können sich auf GitHub Actions verlassen, um das .NET SDK in Ihrem Workflow zu installieren. Die empfohlene Möglichkeit zum Installieren des .NET SDK in einem Workflow ist die actions/setup-net-core-sdk Aktion. Weitere Informationen finden Sie unter Einrichten des .NET Core SDK im GitHub Marketplace. Beispiele dafür finden Sie unter Schnellstart: Erstellen eines GitHub-Workflows für die Buildüberprüfung.

Native Installationsprogramme

Native Installationsprogramme stehen für macOS, Linux und Windows zur Verfügung. Für die Installationsprogramme benötigen Sie Administratorzugriff (sudo) auf den Buildserver. Der Vorteil der Verwendung eines nativen Installationsprogramms liegt darin, dass alle nativen Abhängigkeiten installiert werden, die zum Ausführen der Tools benötigt werden. Native Installationsprogramme ermöglichen außerdem eine systemweite Installation des SDK.

macOS-Benutzer sollten die PKG-Installationsprogramme verwenden. Unter Linux können Sie entweder einen feedbasierten Paket-Manager, z.B. apt-get für Ubuntu oder yum für CentOS, oder die Pakete selbst (also DEB oder RPM) verwenden. Verwenden Sie unter Windows den MSI-Installer.

Die neuesten stabilen Binärdateien finden Sie unter .NET Downloads. Wenn Sie die neuesten (und möglicherweise instabilen) Vorabversionstools verwenden möchten, verwenden Sie die Links im GitHub-Repository dotnet/installer. Für Linux-Distributionen tar.gz sind Archive (auch bekannt als tarballs) verfügbar. Verwenden Sie die Installationsskripts in den Archiven, um .NET zu installieren.

Installerskript

Das Installationsprogrammskript ermöglicht eine Installation ohne Administratorrechte auf dem Buildserver und bietet eine einfache Automatisierung zum Download der Tools. Das Skript kümmert sich um das Herunterladen der Tools und extrahiert diese zur Verwendung an einem Standardspeicherort bzw. dem von Ihnen angegebenen Speicherort. Sie können außerdem angeben, welche Version der Tools Sie verwenden möchten und ob das gesamte SDK oder nur die freigegebene Runtime installiert werden soll.

Das Installationsskript ist automatisiert, sodass es zu Beginn des Buildvorgangs ausgeführt wird, um die gewünschte Version des SDK abzurufen und zu installieren. Die gewünschte Version ist die Version des SDK, die zum Erstellen Ihrer Projekte benötigt wird. Das Skript ermöglicht es Ihnen, das SDK in einem lokalen Verzeichnis auf dem Server zu installieren, die Tools vom Installationsort auszuführen und nach der Builderstellung eine Bereinigung durchzuführen (Sie können die Bereinigung auch dem CI-Dienst überlassen). Dies ermöglicht eine Kapselung und Isolation Ihres gesamten Buildprozesses. Die Referenz zu den Installationsskripts finden Sie im Artikel dotnet-install.

Hinweis

Azure DevOps Services

Bei Verwendung des Installationsskripts werden native Abhängigkeiten nicht automatisch installiert. Sie müssen die nativen Abhängigkeiten installieren, wenn das Betriebssystem diese nicht umfasst. Weitere Informationen finden Sie unter .NET-Abhängigkeiten und -Anforderungen.

Beispiele für die CI-Einrichtung

In diesem Abschnitt wird eine manuelle Einrichtung mithilfe eines PowerShell- oder Bash-Skripts zusammen mit Beschreibungen von Software-as-a-Service-CI-Lösungen (SaaS) beschrieben. Die behandelten SaaS-CI-Lösungen sind Travis CI, AppVeyor und Azure Pipelines. GitHub Actions finden Sie unter GitHub Actions und .NET.

Manuelle Einrichtung

Jeder SaaS-Dienst verfügt über seine Methoden zum Erstellen und Konfigurieren eines Buildprozesses. Wenn Sie eine andere SaaS-Lösung als die aufgeführten verwenden oder eine Anpassung über die vorab gepackte Unterstützung hinaus erfordern, müssen Sie mindestens eine manuelle Konfiguration durchführen.

Im Allgemeinen müssen Sie bei einer manuellen Einrichtung eine Version der Tools (oder die neuesten nächtlichen Builds der Tools) herunterladen und Ihr Buildskript ausführen. Sie können die .NET-Befehle mithilfe eines PowerShell- oder ein Bash-Skripts orchestrieren oder eine Projektdatei verwenden, die den Buildprozess beschreibt. Diese Optionen werden im Abschnitt zur Orchestrierung weiter ausgeführt.

Nachdem Sie ein Skript zur Ausführung eines manuellen Setups eines CI-Buildservers erstellt haben, verwenden Sie es auf Ihrem Entwicklungscomputer, um lokalen Code zu Testzwecken zu erstellen. Nachdem Sie sich davon überzeugt haben, dass das Skript lokal wie erwartet funktioniert, stellen Sie es auf Ihrem CI-Buildserver bereit. Dieses relativ simple PowerShell-Skript zeigt, wie Sie das .NET SDK herunterladen und auf einem Windows-Buildserver installieren:

Sie stellen die Implementierung für Ihren Buildprozess am Ende des Skripts bereit. Das Skript ruft die Tools ab und führt dann Ihren Buildprozess aus.

$ErrorActionPreference="Stop"
$ProgressPreference="SilentlyContinue"

# $LocalDotnet is the path to the locally-installed SDK to ensure the
#   correct version of the tools are executed.
$LocalDotnet=""
# $InstallDir and $CliVersion variables can come from options to the
#   script.
$InstallDir = "./cli-tools"
$CliVersion = "6.0.7"

# Test the path provided by $InstallDir to confirm it exists. If it
#   does, it's removed. This is not strictly required, but it's a
#   good way to reset the environment.
if (Test-Path $InstallDir)
{
    rm -Recurse $InstallDir
}
New-Item -Type "directory" -Path $InstallDir

Write-Host "Downloading the CLI installer..."

# Use the Invoke-WebRequest PowerShell cmdlet to obtain the
#   installation script and save it into the installation directory.
Invoke-WebRequest `
    -Uri "https://dot.net/v1/dotnet-install.ps1" `
    -OutFile "$InstallDir/dotnet-install.ps1"

Write-Host "Installing the CLI requested version ($CliVersion) ..."

# Install the SDK of the version specified in $CliVersion into the
#   specified location ($InstallDir).
& $InstallDir/dotnet-install.ps1 -Version $CliVersion `
    -InstallDir $InstallDir

Write-Host "Downloading and installation of the SDK is complete."

# $LocalDotnet holds the path to dotnet.exe for future use by the
#   script.
$LocalDotnet = "$InstallDir/dotnet"

# Run the build process now. Implement your build script here.

Travis CI

Travis CI kann so konfiguriert werden, dass das .NET SDK mit der Sprache csharp und dem Schlüssel dotnet installiert wird. Weitere Informationen zum Erstellen eines C#-, F#- oder Visual Basic-Projekts finden Sie in der offiziellen Travis CI-Dokumentation. Beachten Sie beim Zugriff auf die Travis CI-Informationen, dass der von der Community verwaltet Sprachbezeichner language: csharp für alle .NET-Sprachen (einschließlich F# und Mono) funktioniert.

Travis CI führt sowohl macOS- als auch Linux-Aufträge in einer Buildmatrix aus, in der Sie eine Kombination aus Runtime, Umgebung und Ausschlüssen/Einschlüssen angeben, um die Buildkombinationen für Ihre App abzudecken. Weitere Informationen finden Sie im Artikel Customizing the Build (Anpassen des Builds) in der Travis CI-Dokumentation. Die MSBuild-basierten Tools umfassen die Laufzeiten long-term support (LTS) und Standard Term Support (STS) im Paket. Wenn Sie also das SDK installieren, erhalten Sie alles, was Sie zum Erstellen benötigen.

AppVeyor

AppVeyor installiert das .NET 6.0.0 SDK mit dem Visual Studio 2022 Build workerimage. Weitere Buildimages mit anderen Versionen des .NET SDK sind verfügbar. Weitere Informationen finden Sie in dem Artikel mit dem appveyor.yml-Beispiel und dem Artikel Build Worker images in der AppVeyor-Dokumentation.

Die .NET SDK-Binärdateien werden mithilfe des Installationsskripts heruntergeladen, in einem Unterverzeichnis entpackt und anschließend der Umgebungsvariable PATH hinzugefügt. Fügen Sie eine Buildmatrix hinzu, um Integrationstests mit mehreren Versionen des .NET SDK auszuführen:

environment:
  matrix:
    - CLI_VERSION: 6.0.7
    - CLI_VERSION: Latest

install:
  # See appveyor.yml example for install script

Azure DevOps Services

Verwenden Sie einen dieser Ansätze, um Azure DevOps Services zum Erstellen von .NET-Projekten zu konfigurieren:

  1. Führen Sie das Skript aus dem Schritt für die manuelle Einrichtung unter Verwendung Ihrer Befehle aus.
  2. Erstellen Sie einen Build aus verschiedenen integrierten Azure DevOps Services-Buildtasks, die zur Verwendung der .NET-Tools konfiguriert sind.

Beide Ansätze sind gültige Vorgehensweisen. Mithilfe eines Skripts zur manuellen Einrichtung kontrollieren Sie, welche Version der Tools abgerufen wird, weil Sie die Tools im Rahmen des Builds herunterladen. Der Build wird aus einem Skript ausgeführt, das Sie erstellen müssen. In diesem Artikel wird nur die manuelle Option behandelt. Weitere Informationen zum Erstellen eines Builds mit Azure DevOps Services-Buildaufgaben finden Sie in der Azure Pipelines-Dokumentation.

Um ein Skript für ein manuelles Setup in Azure DevOps Services zu verwenden, erstellen Sie eine neue Builddefinition und geben das Skript an, das für den Buildschritt ausgeführt werden soll. Dies wird mithilfe der Azure DevOps Services-Benutzeroberfläche erreicht:

  1. Beginnen Sie, indem Sie eine neue Builddefinition erstellen. Wenn der Bildschirm angezeigt wird, auf dem Sie angeben können, welche Art von Build Sie erstellen möchten, wählen Sie die Option Leer aus.

    Auswahl einer leeren Builddefinition

  2. Nachdem Sie das zu erstellende Repository konfiguriert haben, gelangen Sie zu den Builddefinitionen. Wählen Sie Buildschritt hinzufügen aus:

    Hinzufügen eines Buildschritts

  3. Als Nächstes wird der Taskkatalog angezeigt. Der Katalog enthält Tasks, die Sie im Build verwenden. Da Sie über ein Skript verfügen, klicken Sie auf die Schaltfläche Hinzufügen für PowerShell: PowerShell-Skript ausführen.

    Hinzufügen eines Schritts für ein PowerShell-Skript

  4. Konfigurieren Sie den Buildschritt. Fügen Sie das Skript aus dem Repository hinzu, das Sie erstellen:

    Angeben des auszuführenden PowerShell-Skripts

Orchestrieren des Builds

In den meisten Dieser Dokumente wird beschrieben, wie Sie die .NET-Tools abrufen und verschiedene CI-Dienste konfigurieren, ohne Informationen zur Orchestrierung oder tatsächlichen Erstellung Ihres Codes mit .NET bereitzustellen. Die Auswahl bei der Strukturierung des Buildprozesses hängt von vielen Faktoren ab, die hier nicht allgemein abgedeckt werden können. Um weitere Informationen zur Orchestrierung Ihrer Builds mit jeder Technologie zu erhalten, erkunden Sie die Ressourcen und Beispiele in der Dokumentation von Travis CI, AppVeyor und Azure Pipelines.

Bei der Strukturierung des Buildprozesses für .NET-Code unter Verwendung der .NET-Tools können zwei allgemeine Ansätze verfolgt werden: die direkte Verwendung von MSBuild oder die Verwendung von .NET-Befehlszeilenbefehlen. Sie sollten den verwendeten Ansatz danach auswählen, wie vertraut Sie mit dem jeweiligen Ansatz sind und welche Kompromisse Sie in Bezug auf die Komplexität eingehen möchten. Mit MSBuild können Sie Ihren Buildprozess in Form von Tasks und Zielen beschrieben, Sie müssen jedoch die MSBuild-Projektdateisyntax beherrschen. Die Verwendung von .NET-Befehlszeilentools ist möglicherweise einfacher, erfordert aber, dass Sie Orchestrierungslogik in einer Skriptsprache wie bash oder PowerShell schreiben.

Siehe auch