Entwickeln, Testen und Bereitstellen von .NET Core-Apps

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Verwenden Sie eine Azure Pipeline, um Ihre .NET Core-Projekte automatisch zu erstellen, zu testen und bereitzustellen. In diesem Artikel wird gezeigt, wie Sie Folgendes durchführen:

Voraussetzungen

Erstellen Ihrer ersten Pipeline

Sie sind mit Azure Pipelines noch nicht vertraut? In diesem Fall sollten Sie zuerst den folgenden Abschnitt ausprobieren.

Erstellen eines .NET-Projekts.

Wenn Sie noch kein .NET-Projekt haben, mit dem Sie arbeiten können, erstellen Sie ein neues auf Ihrem lokalen System. Installieren Sie zunächst das neueste .NET 8.0 SDK .

1. Öffnen Sie ein Terminalfenster.

2. Erstellen Sie ein Projektverzeichnis, und wechseln Sie zu diesem Verzeichnis.

3. Erstellen Sie eine neue .NET 8-Webapp.

   dotnet new webapp -f net8.0
   

4. Führen Sie in derselben Terminalsitzung die Anwendung lokal aus, indem Sie den dotnet run Befehl aus Ihrem Projektverzeichnis verwenden.

   dotnet run
   

5. Sobald die Anwendung gestartet ist, drücken Sie STRG-C, um sie zu beenden.

Erstellen Sie ein Git-Repo, und verbinden Sie es mit GitHub

1. Erstellen Sie aus dem Projektverzeichnis ein lokales Git-Repository und committen Sie den Anwendungscode zum Mainbranch.

2. Verbinden Sie Ihr lokales Git-Repository mit einem GitHub-Repository.

Erstellen eines DevOps-Projekts

Einrichten Ihrer Build-Umgebung

steps:
- task: UseDotNet@2
  inputs:
    version: '8.x'

Erstellen Ihrer Pipeline

Sie können den YAML-Pipeline-Editor oder den klassischen Editor verwenden, um Ihre Pipeline zu erstellen. Um den klassischen Editor zu verwenden, wählen Sie Klassischen Editor verwenden aus.

Sie verfügen jetzt über eine funktionierende Pipeline, die Sie anpassen können. Lesen Sie weiter, um einige der üblichen Möglichkeiten zur Anpassung Ihrer Pipeline kennenzulernen.

Buildumgebung

pool:
  name: myPrivateAgents
  demands:
  - agent.os -equals Darwin
  - anotherCapability -equals somethingElse

steps:
- task: UseDotNet@2
  displayName: 'Install .NET Core SDK'
  inputs:
    version: 8.x
    performMultiLevelLookup: true
    includePreviewVersions: true # Required for preview versions

pool:
  vmImage: 'ubuntu-latest' 

steps:
- task: UseDotNet@2
  inputs:
    version: '5.x'

steps:
- task: UseDotNet@2
  displayName: 'Install .NET Core SDK'
  inputs:
    version: 8.x
    performMultiLevelLookup: true
    includePreviewVersions: true # Required for preview versions

Wiederherstellen von Abhängigkeiten

NuGet ist eine beliebte Methode zum Herstellen einer Abhängigkeit von Code, den Sie nicht erstellen. Sie können NuGet-Pakete und projektspezifische Tools herunterladen, die in der Projektdatei angegeben sind, indem Sie den Befehl dotnet restore entweder über die .NET Core-Aufgabe oder direkt in einem Skript in Ihrer Pipeline ausführen. Weitere Informationen finden Sie unter .NET Core-Aufgabe (DotNetCoreCLI@2).

Sie können NuGet-Pakete auch aus Azure Artifacts, NuGet.org oder einem anderen externen oder internen NuGet-Repository herunterladen. Die .NET Core-Aufgabe ist besonders nützlich, um Pakete aus authentifizierten NuGet-Feeds wiederherzustellen. Wenn sich Ihr Feed in demselben Projekt wie Ihre Pipeline befindet, müssen Sie sich nicht authentifizieren.

Diese Pipeline verwendet einen Azure Artifact-Feed für dotnet restore in der DotNetCoreCLI@2 Aufgabe.

trigger:
- main

pool:
  vmImage: 'windows-latest'

steps:
- task: UseDotNet@2
  displayName: 'Install .NET Core SDK'
  inputs:
    version: 8.x
    performMultiLevelLookup: true
    includePreviewVersions: true # Required for preview versions

variables:
  buildConfiguration: 'Release'

steps:
- task: DotNetCoreCLI@2
  inputs:
    command: 'restore'
    feedsToUse: 'select'
    vstsFeed: 'my-vsts-feed' # A series of numbers and letters

- task: DotNetCoreCLI@2
  inputs:
    command: 'build'
    arguments: '--configuration $(buildConfiguration)'
  displayName: 'dotnet build $(buildConfiguration)'

Der Befehl dotnet restore verwendet das mit dem .NET Core SDK verpackte NuGet.exe und kann nur Pakete wiederherstellen, die in den .csproj-Dateien des .NET Core-Projekts angegeben sind.

Wenn Sie auch ein Microsoft .NET Framework-Projekt in Ihrer Projektmappe haben oder package.json zum Angeben Ihrer Abhängigkeiten nutzen, verwenden Sie die NuGet-Aufgabe, um diese Abhängigkeiten wiederherzustellen.

- task: NuGetCommand@2
  inputs:
    command: 'restore'
    restoreSolution: '**/*.sln'
    feedsToUse: 'select'

In .NET Core SDK Version 2.0 und neuer werden die Pakete automatisch wiederhergestellt, wenn Sie Befehle wie dotnet build ausführen. Sie müssen jedoch weiterhin die Aufgabe .NET Core verwenden, um Pakete wiederherzustellen, wenn Sie einen authentifizierten Feed verwenden.

Ihre Builds können aufgrund von Verbindungsproblemen fehlschlagen, wenn Sie Pakete von NuGet.org wiederherstellen. Sie können Azure Artifacts mit Upstream-Quellen verwenden, um die Pakete zwischenzuspeichern. Die Anmeldedaten der Pipeline werden beim Herstellen einer Verbindung mit Azure Artifacts automatisch verwendet. Diese Anmeldeinformationen werden in der Regel vom Projektsammlungs-Builddienst-Konto abgeleitet. Um mehr über die Verwendung von Azure Artifacts zum Zwischenspeichern Ihrer NuGet-Pakete zu erfahren, lesen Sie Verbindung zu Azure Artifact-Feeds.

Um ein NuGet-Repository anzugeben, geben Sie die URL in einer NuGet.config-Datei in Ihrem Repository an. Wenn Ihr Feed authentifiziert ist, verwalten Sie die zugehörigen Anmeldeinformationen, indem Sie eine NuGet-Dienstverbindung auf der Registerkarte Dienste unter Projekteinstellungen erstellen.

Weitere Informationen zu NuGet-Dienstverbindungen finden Sie unter Veröffentlichen in NuGet-Feeds.

Pakete aus einem externen Feed wiederherstellen

Gehen Sie wie folgt vor, um Pakete aus einem externen Feed wiederherzustellen.

# do this before your build tasks
steps:
- task: DotNetCoreCLI@2
  displayName: Restore
  inputs:
    command: restore
    projects: '**/*.csproj'
    feedsToUse: config
    nugetConfigPath: NuGet.config    # Relative to root of the repository
    externalFeedCredentials: <Name of the NuGet service connection>

Erstellen Ihres Projekts

Führen Sie Ihre .NET Core-Projekte mit dem Befehl dotnet build aus. Sie können den Befehl als Kommandozeilen-Skript zu Ihrer Pipeline hinzufügen oder die .NET Core-Aufgabe verwenden.

.NET Core-Build mit der .NET Core-Aufgabe ausführen

YAML-Beispiel zum Ausführen eines Builds mit der Aufgabe DotNetCoreCLI@2:

steps:
- task: DotNetCoreCLI@2
  displayName: Build
  inputs:
    command: build
    projects: '**/*.csproj'
    arguments: '--configuration $(buildConfiguration)' # Update this to match your needs

.NET Core-Build mit einem Kommandozeilen-Skript ausführen

YAML-Beispiel zum Ausführen eines Builds mit dotnet build als Skript:

steps:
- script: dotnet build --configuration $(buildConfiguration)
  displayName: 'dotnet build $(buildConfiguration)'

Hinzufügen von .NET SDK-Befehlen zu Ihrer Pipeline

Sie können .NET SDK-Befehle als Skript oder mit Hilfe der .NET Core-Aufgabe zu Ihrem Projekt hinzufügen. Die .NET Core-Aufgabe (DotNetCoreCLI@2) ermöglicht es Ihnen, Ihrer Pipeline ganz einfach .NET-CLI-Befehle hinzuzufügen. Sie können .NET Core-Aufgaben hinzufügen, indem Sie Ihre YAML-Datei bearbeiten oder den klassischen Editor verwenden.

Hinzufügen eines .NET-CLI-Befehls mit der .NET Core-Aufgabe

Hinzufügen eines .NET Core-CLI-Befehls mithilfe eines Skripts

Sie können .NET Core-CLI-Befehle als script in Ihre azure-pipelines.yml-Datei einfügen.

Beispiel:

steps:
# ...
- script: dotnet test <test-project> 

Installieren eines Tools

Führen Sie die folgenden Schritte aus, um ein globales .NET Core-Tool wie dotnetsay in Ihrem Build unter Windows zu installieren:

1. Fügen Sie die .NET Core-Aufgabe hinzu, und legen Sie die folgenden Eigenschaften fest:
   • Befehl: custom.
     • Pfad zu Projekten: leer lassen.
   • Benutzerdefinierter Befehl: tool.
   • Argumente: install -g dotnetsay.
2. Um das Tool auszuführen, fügen Sie eine Befehlszeile hinzu und legen Sie die folgenden Eigenschaften fest:
   • Skript: dotnetsay.

Ausführen der Tests

Wenn Sie Testprojekte in Ihrem Repository haben, können Sie die .NET Core-Aufgabe verwenden, um Unit-Tests unter Verwendung von Test-Frameworks wie MSTest, xUnit und NUnit auszuführen. Das Testprojekt muss auf Microsoft.NET.Test.SDK, Version 15.8.0 oder höher, verweisen. Die Testergebnisse werden automatisch in dem Dienst veröffentlicht. Diese Ergebnisse stehen Ihnen in der Buildzusammenfassung zur Verfügung und können für die Problembehandlung fehlgeschlagener Tests und die Analyse der Testzeitplanung verwendet werden.

Sie können Ihrer Pipeline mit der Aufgabe DotNetCoreCLI@2 eine Testaufgabe hinzufügen oder den folgenden Code-Ausschnitt zu Ihrer azure-pipelines.yml-Datei hinzufügen:

steps:
# ...
# do this after other tasks such as building
- task: DotNetCoreCLI@2
  inputs:
    command: test
    projects: '**/*Tests/*.csproj'
    arguments: '--configuration $(buildConfiguration)'

Wenn Sie den .NET Core-Aufgabeneditor verwenden, legen Sie Befehl auf Test fest. Pfad zu Projekten sollte sich auf die Testprojekte in Ihrer Lösung beziehen.

Alternativ können Sie den Befehl dotnet test mit einem bestimmten Logger ausführen und dann die Aufgabe Testergebnisse veröffentlichen verwenden:

steps:
# ...
# do this after your tests have run
- script: dotnet test <test-project> --logger trx
- task: PublishTestResults@2
  condition: succeededOrFailed()
  inputs:
    testRunner: VSTest
    testResultsFiles: '**/*.trx'

Sammeln von Code Coverage

Wenn Sie unter Windows Builds erstellen, können Sie Kennzahlen zur Code-Abdeckung mit dem integrierten Daten-Collector erfassen. Das Testprojekt muss auf Microsoft.NET.Test.SDK, Version 15.8.0 oder höher, verweisen.

Wenn Sie die .NET Core-Aufgabe verwenden, um Tests auszuführen, werden die Abdeckungsdaten automatisch auf dem Server veröffentlicht. Die .coverage-Datei kann von der Build-Zusammenfassung heruntergeladen und in Visual Studio angezeigt werden.

Fügen Sie Ihrer Datei azure-pipelines.yml das folgende Codeschnipsel hinzu:

steps:
# ...
# do this after other tasks such as building
- task: DotNetCoreCLI@2
  inputs:
    command: test
    projects: '**/*Tests/*.csproj'
    arguments: '--configuration $(buildConfiguration) --collect "Code coverage"'

So fügen Sie die Aufgabe .NET Core über den Aufgabeneditor hinzu:

1. Fügen Sie dem Buildauftrag die .NET Core-Aufgabe hinzu, und legen Sie die folgenden Eigenschaften fest:

   1. Befehl: test.
   2. Pfad zu Projekten: Sollte auf die Testprojekte in Ihrer Projektmappe verweisen.
   3. Argumente: --configuration $(BuildConfiguration) --collect "Code coverage".

2. Stellen Sie sicher, dass die Option Testergebnisse veröffentlichen ausgewählt bleibt.

Wenn Sie den Befehl dotnet test ausführen möchten, geben Sie die Optionen für Testergebnisprotokollierung und Abdeckung an. Verwenden Sie dann die Aufgabe Testergebnisse veröffentlichen:

steps:
# ...
# do this after your tests have run
- script: dotnet test <test-project> --logger trx --collect "Code coverage"
- task: PublishTestResults@2
  inputs:
    testRunner: VSTest
    testResultsFiles: '**/*.trx'

Sammeln von Code Coverage-Metriken mit Coverlet

Wenn Sie Builds unter Linux oder macOS erstellen, können Sie Coverlet oder ein ähnliches Tool verwenden, um Code Coverage-Metriken zu sammeln.

Sie können die Ergebnisse der Code-Abdeckung mit der Aufgabe Code-Abdeckungsergebnisse veröffentlichen (PublishCodeCoverageResults@1) auf dem Server veröffentlichen. Das Abdeckungstool muss so konfiguriert sein, dass Ergebnisse im Cobertura- oder JaCoCo-Abdeckungsformat generiert werden.

Führen Sie die folgenden Aufgaben aus, um Tests auszuführen und Code Coverage mit Coverlet zu veröffentlichen:

• Fügen Sie einen Verweis auf das NuGet-Paket coverlet.collector hinzu.

• Fügen Sie Ihrer Datei azure-pipelines.yml das folgende Codeschnipsel hinzu:

  - task: UseDotNet@2
    inputs:
      version: '8.x'
      includePreviewVersions: true # Required for preview versions
  
  - task: DotNetCoreCLI@2
    displayName: 'dotnet build'
    inputs:
      command: 'build'
      configuration: $(buildConfiguration)
  
  - task: DotNetCoreCLI@2
    displayName: 'dotnet test'
    inputs:
      command: 'test'
      arguments: '--configuration $(buildConfiguration) --collect:"XPlat Code Coverage" -- DataCollectionRunSettings.DataCollectors.DataCollector.Configuration.Format=cobertura'
      publishTestResults: true
      projects: 'MyTestLibrary' # update with your test project directory
  
  - task: PublishCodeCoverageResults@1
    displayName: 'Publish code coverage report'
    inputs:
      codeCoverageTool: 'Cobertura'
      summaryFileLocation: '$(Agent.TempDirectory)/**/coverage.cobertura.xml'
  

Verpacken und Übermitteln von Code

Sie können Ihre Build-Artefakte folgendermaßen veröffentlichen:

• Veröffentlichen in Azure Pipelines
• Veröffentlichen von Paketen in Azure Artifacts
• Erstellen Sie ein NuGet-Paket, und veröffentlichen Sie es in Ihrem NuGet-Feed.
• Erstellen eines .ZIP-Archivs zur Bereitstellung Ihrer Web-App.

Veröffentlichen von Artefakten in Azure Pipelines

steps:

- task: DotNetCoreCLI@2
  inputs:
    command: publish
    publishWebProjects: True
    arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
    zipAfterPublish: True

# this code takes all the files in $(Build.ArtifactStagingDirectory) and uploads them as an artifact of your build.
- task: PublishPipelineArtifact@1
  inputs:
    targetPath: '$(Build.ArtifactStagingDirectory)' 
    artifactName: 'myWebsite'

steps:

- task: DotNetCoreCLI@2
  inputs:
    command: publish
    publishWebProjects: True
    arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
    zipAfterPublish: True

# this code takes all the files in $(Build.ArtifactStagingDirectory) and uploads them as an artifact of your build.
- task: PublishBuildArtifacts@1
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
    ArtifactName: 'drop'

Veröffentlichen in einem NuGet-Feed

Um ein NuGet-Paket zu erstellen und es in Ihrem NuGet Feed zu veröffentlichen, fügen Sie den folgenden Code-Ausschnitt hinzu:

steps:
# ...
# do this near the end of your pipeline in most cases
- script: dotnet pack /p:PackageVersion=$(version)  # define version variable elsewhere in your pipeline
- task: NuGetAuthenticate@1
  inputs:
    nuGetServiceConnections: '<Name of the NuGet service connection>'
- task: NuGetCommand@2
  inputs:
    command: push
    nuGetFeedType: external
    publishFeedCredentials: '<Name of the NuGet service connection>'
    versioningScheme: byEnvVar
    versionEnvVar: version

Weitere Informationen zur Versionsverwaltung und zur Veröffentlichung von NuGet-Paketen finden Sie unter Veröffentlichen von NuGet-Feeds.

Veröffentlichen eines NuGet-Pakets in Azure Artifacts

Sie können Ihre NuGet-Pakete in Ihrem Azure Artifacts-Feed veröffentlichen, indem Sie NuGetCommand@2 verwenden, um zu Ihrem Azure Artifact-Feed zu pushen. Siehe zum Beispiel NuGet-Pakete mit Azure Pipelines veröffentlichen.

Bereitstellen einer Web-App

Um ein ZIP-Archiv zu erstellen, das bereit ist, in einer Web-App veröffentlicht zu werden, fügen Sie den folgenden Code-Ausschnitt ein:

steps:
# ...
# do this after you've built your app, near the end of your pipeline in most cases
# for example, you do this before you deploy to an Azure web app on Windows
- task: DotNetCoreCLI@2
  inputs:
    command: publish
    publishWebProjects: True
    arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
    zipAfterPublish: True

Informationen zum Veröffentlichen dieses Archivs in einer Web-App finden Sie unter Azure-Web-App-Bereitstellung.

Erstellen eines Images und Pushen in eine Containerregistrierung

Sie können auch ein Image für Ihre App erstellen und es in eine Container-Registry pushen.

Veröffentlichen von Symbolen

Sie können die PublishSymbols@2-Aufgabe verwenden, um Symbole für einen Azure Artifacts-Symbolserver oder eine Dateifreigabe zu veröffentlichen.

Wenn Sie beispielsweise Symbole in einer Dateifreigabe veröffentlichen möchten, fügen Sie der azure-pipelines.yml-Datei den folgenden Codeausschnitt hinzu:

- task: PublishSymbols@2
  inputs:
    SymbolsFolder: '$(Build.SourcesDirectory)'
    SearchPattern: '**/bin/**/*.pdb'
    IndexSources: true
    PublishSymbols: true
    SymbolServerType: 'FileShare' 
    SymbolsPath: '\\server\shareName'

Wenn Sie den klassischen Editor verwenden, wählen Sie Indizieren von Quellen und Veröffentlichen von Symbolen aus dem Aufgabenkatalog aus, um sie der Pipeline hinzuzufügen.

Weitere Informationen finden Sie unter Symbole veröffentlichen.

Problembehandlung

Wenn Sie Ihr Projekt auf Ihrem Entwicklungscomputer erstellen können, aber Probleme beim Erstellen in Azure Pipelines auftreten, untersuchen Sie die folgenden möglichen Ursachen und Korrekturmaßnahmen:

• Überprüfen Sie die .NET Core SDK-Versionen und -Runtime auf Ihrem Entwicklungscomputer, und stellen Sie sicher, dass sie mit dem Agent übereinstimmen. Sie können ein Befehlszeilenskript dotnet --version in Ihre Pipeline einschließen, um die Version des .NET Core SDK zu drucken. Verwenden Sie entweder den .NET Core Tool-Installer, um dieselbe Version auf dem Agent bereitzustellen, oder aktualisieren Sie Ihre Projekte und Ihren Entwicklungscomputer auf die neuere Version des .NET Core SDK.

• Möglicherweise verwenden Sie Logik in der Visual Studio-IDE, die in Ihrer Pipeline nicht codiert ist. Azure Pipelines führt jeden der Befehle, die Sie in den Aufgaben angeben, nacheinander in einem neuen Prozess aus. Untersuchen Sie die Protokolle aus dem Pipelinebuild, um die genauen Befehle anzuzeigen, die im Rahmen des Builds ausgeführt wurden. Wiederholen Sie dieselben Befehle in derselben Reihenfolge auf Ihrem Entwicklungscomputer, um das Problem zu finden.

• Wenn Sie über eine gemischte Projektmappe verfügen, die einige .NET Core-Projekte und einige .NET Framework-Projekte enthält, sollten Sie auch die NuGet-Aufgabe verwenden, um in packages.config-Dateien angegebene Pakete wiederherzustellen. Fügen Sie die Aufgabe MSBuild oder Visual Studio-Build hinzu, um die .NET Framework-Projekte zu erstellen.

• Es kann sein, dass Ihre Builds beim Wiederherstellen von Paketen zeitweise fehlschlagen: Entweder hat NuGet.org Probleme, oder es gibt Netzwerkprobleme zwischen dem Azure-Rechenzentrum und NuGet.org. Sie können feststellen, ob die Verwendung von Azure Artifacts mit NuGet.org als Upstream-Quelle die Zuverlässigkeit Ihrer Builds verbessert, da dies nicht in unserem Einflussbereich liegt.

• Wenn eine neue Version des .NET Core SDKs oder von Visual Studio veröffentlicht wird, kann es gelegentlich vorkommen, dass Ihr Build nicht funktioniert. Zum Beispiel könnte eine neuere Version oder Funktion des NuGet Tools, das mit dem SDK ausgeliefert wird, Ihren Build beeinträchtigen. Um dieses Problem einzugrenzen, verwenden Sie die Aufgabe .NET Core Tool-Installer, um die in Ihrem Build verwendete Version des .NET Core SDK anzugeben.

Häufig gestellte Fragen

F: Wo kann ich mehr über Azure Artifacts erfahren?

A: Paketverwaltung in Azure Artifacts

F: Wo erfahre ich mehr über .NET Core-Befehle?

A: .NET Core-CLI-Tools

F: Wo erhalte ich weitere Informationen zum Ausführen von Tests in meiner Projektmappe?

A: Komponententests in .NET Core-Projekten

F: Wo erfahre ich mehr über Aufgaben?

A: Entwickeln und Veröffentlichen von Aufgaben