De .NET SDK gebruiken in CI-omgevingen (Continuous Integration)

In dit artikel wordt beschreven hoe u de .NET SDK en de bijbehorende hulpprogramma's op een buildserver gebruikt. De .NET-toolset werkt zowel interactief, waarbij een ontwikkelaar opdrachten typt bij een opdrachtprompt en automatisch, waarbij een CI-server (Continuous Integration) een buildscript uitvoert. De opdrachten, opties, invoer en uitvoer zijn hetzelfde en de enige dingen die u opgeeft, zijn een manier om de hulpprogramma's en een systeem te verkrijgen om uw app te bouwen. Dit artikel is gericht op scenario's voor het verkrijgen van hulpprogramma's voor CI met aanbevelingen voor het ontwerpen en structureren van uw buildscripts.

Installatieopties voor CI-buildservers

Als u GitHub gebruikt, is de installatie heel eenvoudig. U kunt vertrouwen op GitHub Actions om de .NET SDK in uw werkstroom te installeren. De aanbevolen manier om de .NET SDK in een werkstroom te installeren, is met de actions/setup-net-core-sdk. Zie de actie .NET Core SDK instellen in de GitHub Marketplace voor meer informatie. Zie Quickstart: Een GitHub-werkstroom voor buildvalidatie maken voor voorbeelden van hoe dit werkt.

Systeemeigen installatieprogramma's

Systeemeigen installatieprogramma's zijn beschikbaar voor macOS, Linux en Windows. Voor de installatieprogramma's is beheerderstoegang (sudo) tot de buildserver vereist. Het voordeel van het gebruik van een systeemeigen installatieprogramma is dat alle systeemeigen afhankelijkheden worden geïnstalleerd die nodig zijn om de hulpprogramma's uit te voeren. Systeemeigen installatieprogramma's bieden ook een systeembrede installatie van de SDK.

macOS-gebruikers moeten de PKG-installatieprogramma's gebruiken. In Linux is er een keuze uit het gebruik van een feedgebaseerde pakketbeheerder, zoals apt-get voor Ubuntu of yum voor CentOS, of het gebruik van de pakketten zelf, DEB of RPM. Gebruik in Windows het MSI-installatieprogramma.

De meest recente stabiele binaire bestanden vindt u op .NET-downloads. Als u de meest recente (en mogelijk instabiele) hulpprogramma's voor de voorlopige release wilt gebruiken, gebruikt u de koppelingen in de GitHub-opslagplaats dotnet/installer. Voor Linux-distributies zijn archieven (ook wel bekend als tarballs) beschikbaar; gebruik de installatiescripts tar.gz in de archieven om .NET te installeren.

Installatiescript

Met behulp van het installatiescript kunt u niet-beheer installeren op uw buildserver en eenvoudige automatisering voor het verkrijgen van de hulpprogramma's. Het script zorgt ervoor dat de hulpprogramma's worden gedownload en geëxtraheerd naar een standaardlocatie of opgegeven locatie voor gebruik. U kunt ook een versie opgeven van de hulpprogramma's die u wilt installeren en of u de volledige SDK of alleen de gedeelde runtime wilt installeren.

Het installatiescript wordt automatisch uitgevoerd aan het begin van de build om de gewenste versie van de SDK op te halen en te installeren. De gewenste versie is de versie van de SDK die uw projecten nodig hebben om te bouwen. Met het script kunt u de SDK installeren in een lokale map op de server, de hulpprogramma's uitvoeren vanaf de geïnstalleerde locatie en vervolgens opschonen (of de CI-service opschonen) na de build. Dit biedt inkapseling en isolatie voor uw hele buildproces. De naslaginformatie over het installatiescript vindt u in het dotnet-install-artikel .

Notitie

Azure DevOps Services

Wanneer u het installatiescript gebruikt, worden systeemeigen afhankelijkheden niet automatisch geïnstalleerd. U moet de systeemeigen afhankelijkheden installeren als het besturingssysteem deze niet heeft. Zie .NET-afhankelijkheden en -vereisten voor meer informatie.

Voorbeelden van CI-installatie

In deze sectie wordt een handmatige installatie beschreven met behulp van een PowerShell- of bash-script, samen met beschrijvingen van SAAS-oplossingen (Software as a Service). De Behandelde SaaS CI-oplossingen zijn Travis CI, AppVeyor en Azure Pipelines. Zie GitHub Actions en .NET voor GitHub Actions

Handmatige installatie

Elke SaaS-service heeft zijn methoden voor het maken en configureren van een buildproces. Als u een andere SaaS-oplossing gebruikt dan die welke worden vermeld of aanpassingen vereist buiten de vooraf verpakte ondersteuning, moet u ten minste een handmatige configuratie uitvoeren.

Over het algemeen moet u voor een handmatige installatie een versie van de hulpprogramma's (of de nieuwste nachtversies van de hulpprogramma's) verkrijgen en uw buildscript uitvoeren. U kunt een PowerShell- of bash-script gebruiken om de .NET-opdrachten te organiseren of een projectbestand te gebruiken dat het buildproces beschrijft. In de indelingssectie vindt u meer informatie over deze opties.

Nadat u een script hebt gemaakt dat een handmatige INSTALLATIE van de CI-buildserver uitvoert, gebruikt u het op uw ontwikkelcomputer om uw code lokaal te bouwen voor testdoeleinden. Zodra u hebt bevestigd dat het script lokaal goed wordt uitgevoerd, implementeert u het op uw CI-buildserver. Een relatief eenvoudig PowerShell-script laat zien hoe u de .NET SDK verkrijgt en installeert op een Windows-buildserver:

U geeft de implementatie voor uw buildproces aan het einde van het script op. Het script verkrijgt de hulpprogramma's en voert vervolgens uw buildproces uit.

$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

U kunt Travis CI configureren om de .NET SDK te installeren met behulp van de csharp taal en de dotnet sleutel. Zie de officiële Travis CI-documenten over het bouwen van een C#, F# of Visual Basic Project voor meer informatie. Houd er rekening mee dat u de Travis CI-informatie opent die door de community wordt onderhouden language: csharp voor alle .NET-talen, inclusief F#en Mono.

Travis CI voert zowel macOS- als Linux-taken uit in een buildmatrix, waarbij u een combinatie van runtime, omgeving en uitsluitingen/insluitingen opgeeft om uw buildcombinaties voor uw app te dekken. Zie het artikel Build aanpassen in de Travis CI-documentatie voor meer informatie. De OP MSBuild gebaseerde hulpprogramma's bevatten de LTS- en Current-runtimes in het pakket; Dus door de SDK te installeren, ontvangt u alles wat u nodig hebt om te bouwen.

AppVeyor

AppVeyor installeert de .NET 6.0.0 SDK met de Visual Studio 2022 build worker-installatiekopie. Andere build-installatiekopieën met verschillende versies van de .NET SDK zijn beschikbaar. Zie het voorbeeld appveyor.yml en het artikel build worker images in de AppVeyor-documenten voor meer informatie.

De binaire .NET SDK-bestanden worden gedownload en uitgepakt in een submap met behulp van het installatiescript en vervolgens worden ze toegevoegd aan de PATH omgevingsvariabele. Voeg een buildmatrix toe om integratietests uit te voeren met meerdere versies van de .NET SDK:

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

install:
  # See appveyor.yml example for install script

Azure DevOps Services

Configureer Azure DevOps Services om .NET-projecten te bouwen met behulp van een van deze methoden:

  1. Voer het script uit vanuit de handmatige installatiestap met behulp van uw opdrachten.
  2. Maak een build die bestaat uit verschillende ingebouwde buildtaken van Azure DevOps Services die zijn geconfigureerd voor het gebruik van .NET-hulpprogramma's.

Beide oplossingen zijn geldig. Met behulp van een handmatig installatiescript bepaalt u de versie van de hulpprogramma's die u ontvangt, omdat u deze downloadt als onderdeel van de build. De build wordt uitgevoerd vanuit een script dat u moet maken. In dit artikel wordt alleen de handmatige optie besproken. Zie de documentatie over Azure Pipelines voor meer informatie over het opstellen van een build met Azure DevOps Services-buildtaken.

Als u een handmatig installatiescript in Azure DevOps Services wilt gebruiken, maakt u een nieuwe builddefinitie en geeft u het script op dat moet worden uitgevoerd voor de buildstap. Dit wordt bereikt met behulp van de gebruikersinterface van Azure DevOps Services:

  1. Begin met het maken van een nieuwe builddefinitie. Wanneer u bij het scherm bent dat u een optie biedt om te definiëren welk type build u wilt maken, selecteert u de optie Leeg .

    Een lege builddefinitie selecteren

  2. Nadat u de opslagplaats hebt geconfigureerd om te bouwen, wordt u omgeleid naar de builddefinities. Selecteer Build-stap toevoegen:

    Een buildstap toevoegen

  3. U krijgt de taakcatalogus te zien. De catalogus bevat taken die u in de build gebruikt. Omdat u een script hebt, selecteert u de knop Toevoegen voor PowerShell: Voer een PowerShell-script uit.

    Een PowerShell-scriptstap toevoegen

  4. Configureer de buildstap. Voeg het script toe vanuit de opslagplaats die u bouwt:

    Het PowerShell-script opgeven dat moet worden uitgevoerd

De build organiseren

In het meeste van dit document wordt beschreven hoe u de .NET-hulpprogramma's verkrijgt en verschillende CI-services configureert zonder informatie te verstrekken over het organiseren of daadwerkelijk bouwen van uw code met .NET. De keuzes voor het structureren van het bouwproces zijn afhankelijk van veel factoren die hier niet op een algemene manier kunnen worden behandeld. Voor meer informatie over het organiseren van uw builds met elke technologie, verkent u de resources en voorbeelden in de documentatiesets van Travis CI, AppVeyor en Azure Pipelines.

Twee algemene benaderingen die u neemt bij het structureren van het buildproces voor .NET-code met behulp van de .NET-hulpprogramma's, gebruiken MSBuild rechtstreeks of met behulp van de .NET-opdrachtregelopdrachten. Welke aanpak u moet nemen, wordt bepaald door uw comfortniveau met de benaderingen en afwegingen in complexiteit. MSBuild biedt u de mogelijkheid om uw buildproces uit te drukken als taken en doelen, maar het wordt geleverd met de toegevoegde complexiteit van het leren van de syntaxis van het MSBuild-projectbestand. Het gebruik van de .NET-opdrachtregelprogramma's is misschien eenvoudiger, maar hiervoor moet u indelingslogica schrijven in een scripttaal zoals bash of PowerShell.

Zie ook