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 (der Entwickler gibt Befehle in die Eingabeaufforderung ein) als auch automatisch, wenn ein Continuous Integration-Server (CI) 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 für den Tooldownload 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 Methode zum Installieren des .NET SDK in einem Workflow ist die actions/setup-net-core-sdk-Aktion. Weitere Informationen finden Sie in der Aktion Setup .NET Core SDK (Einrichten des .NET Core SDK) auf dem GitHub-Marketplace. Beispiele für die Funktionsweise 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 (möglicherweise instabilen) Vorabversionen der Tools verwenden möchten, nutzen Sie die Links im GitHub-Repository dotnet/installer. Für Linux-Distributionen stehen tar.gz-Archive (auch bekannt als tarballs) zur Verfügung. Verwenden Sie die Installationsskripts in den Archiven, um .NET zu installieren.
Installationsprogrammskript
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 die manuelle Einrichtung unter Verwendung eines PowerShell- oder Bash-Skripts erläutert, und es werden SaaS-CI-Lösungen (Software-as-a-Service) beschrieben. Die behandelten SaaS-CI-Lösungen sind Travis CI, AppVeyor und Azure Pipelines. Informationen zu GitHub Actions finden Sie unter GitHub Actions und .NET.
Manuelle Einrichtung
Jeder SaaS-Dienst umfasst Methoden zum Erstellen und Konfigurieren eines Buildprozesses. Wenn Sie eine andere SaaS-Lösung als die hier aufgeführten verwenden oder eine über die integrierte Unterstützung hinausgehende Anpassung erforderlich ist, müssen Sie einige manuelle Konfigurationsschritte ausfü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, wobei Sie eine Kombination aus Runtime, Umgebung und Einschlüssen/Ausschlüssen zur Abdeckung der Buildkombinationen für Ihre App angeben. Weitere Informationen finden Sie im Artikel Customizing the Build (Anpassen des Builds) in der Travis CI-Dokumentation. Die MSBuild-basierten Tools enthalten die LTS- und STS-Runtimes (Long-Term Support und Short-Term Support) im Paket, sodass Sie mit der Installation des SDK alles erhalten, was Sie zum Erstellen benötigen.
AppVeyor
AppVeyor installiert das .NET 6 SDK mit dem Buildworkerimage Visual Studio 2022. Weitere Buildimages mit anderen Versionen des .NET SDK sind verfügbar. Weitere Informationen finden Sie in der AppVeyor-Dokumentation im Artikel Build worker images.
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
Azure DevOps Services
Verwenden Sie einen dieser Ansätze, um Azure DevOps Services zum Erstellen von .NET-Projekten zu konfigurieren:
- Führen Sie das Skript aus dem Schritt für die manuelle Einrichtung unter Verwendung Ihrer Befehle aus.
- 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:
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.
Nachdem Sie das zu erstellende Repository konfiguriert haben, gelangen Sie zu den Builddefinitionen. Wählen Sie Buildschritt hinzufügen aus:
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.
Konfigurieren Sie den Buildschritt. Fügen Sie das Skript aus dem Repository hinzu, das Sie erstellen:
Orchestrieren des Builds
In diesem Dokument wird hauptsächlich beschrieben, wie Sie die .NET-Tools herunterladen und verschiedene CI-Dienste konfigurieren, ohne darauf einzugehen, wie Sie Ihren Code mit .NET orchestrieren oder tatsächlich einen Build erstellen. 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.
Tipp
Eine MSBuild-Eigenschaft, die Sie auf true festlegen sollten, ist ContinuousIntegrationBuild. Diese Eigenschaft ermöglicht Einstellungen, die nur für offizielle Builds und nicht für lokale Entwicklungsbuilds gelten.
Siehe auch
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für