Freigeben über


Erstellen, Testen und Bereitstellen von .NET Core-Projekten

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

In diesem Artikel wird beschrieben, wie Sie Azure Pipelines verwenden, um mit .NET Core-Projekten zu arbeiten. Der Artikel führt Sie durch die folgenden Aufgaben:

  • Erstellen Sie eine .NET Core-Web-App, und laden Sie sie in ein GitHub-Repository hoch.
  • Erstellen Sie ein Azure DevOps-Projekt und eine Azure Pipelines-Pipeline, um das Projekt zu erstellen.
  • Richten Sie Ihre Buildumgebung mit selbst gehosteten Agents ein.
  • Stellen Sie Abhängigkeiten wieder her, erstellen Sie Ihr Projekt, und testen Sie es mit der .NET Core -Aufgabe (DotNetCoreCLI@2) oder einem Skript.
  • Verwenden Sie die .NET Core (DotNetCoreCLI@2)-Aufgabe, um Ihrer Pipeline weitere .NET SDK-Befehle hinzuzufügen.
  • Verwenden Sie die Aufgabe " Codeabdeckungsergebnisse veröffentlichen" (Publish code coverage results v2Codeabdeckungsergebnisse) zum Veröffentlichen von Codeabdeckungsergebnissen.
  • Packen und übermitteln Sie Die Buildausgabe an Ihre Pipeline, einen NuGet-Feed, ein ZIP-Archiv oder andere Ziele.
  • Erstellen Sie eine .NET Core-Web-App, und laden Sie sie in ein GitHub-Repository hoch.
  • Erstellen Sie ein Azure DevOps-Projekt und eine Azure Pipelines-Pipeline, um das Projekt zu erstellen.
  • Richten Sie Ihre Buildumgebung mit von Microsoft gehosteten oder selbst gehosteten Agents ein.
  • Stellen Sie Abhängigkeiten wieder her, erstellen Sie Ihr Projekt, und testen Sie es mit der .NET Core -Aufgabe (DotNetCoreCLI@2) oder einem Skript.
  • Verwenden Sie die .NET Core (DotNetCoreCLI@2)-Aufgabe, um Ihrer Pipeline weitere .NET SDK-Befehle hinzuzufügen.
  • Verwenden Sie die Aufgabe " Codeabdeckungsergebnisse veröffentlichen" (Publish code coverage results v2Codeabdeckungsergebnisse) zum Veröffentlichen von Codeabdeckungsergebnissen.
  • Packen und übermitteln Sie Die Buildausgabe an Ihre Pipeline, einen NuGet-Feed, ein ZIP-Archiv oder andere Ziele.

Hinweis

Informationen zum Arbeiten mit .NET Framework-Projekten finden Sie unter Build ASP.NET-Apps mit .NET Framework.

Voraussetzungen

Um alle Verfahren in diesem Artikel abzuschließen, benötigen Sie die folgenden Voraussetzungen:

Um alle Verfahren in diesem Artikel abzuschließen, benötigen Sie die folgenden Voraussetzungen:

  • Eine Azure DevOps Sammlung
  • Ein Azure DevOps-Projekt, das in der Organisation erstellt wurde. Anweisungen finden Sie unter Erstellen eines Projekts in Azure DevOps.
  • Mitgliedschaft in der Gruppe "Projektadministratoren", sodass Sie Azure DevOps-Projekte erstellen und Projektzugriff auf Pipelines gewähren können. Besitzer der Azure DevOps-Organisation verfügen automatisch über diese Mitgliedschaft.
  • Die Rolle "Administrator " oder "Ersteller " für Dienstverbindungen, die Sie als Projektadministrator zuweisen können.
  • Ein GitHub-Konto und Repository.

Erstellen eines .NET-Projekts und Hochladen auf GitHub

Wenn Sie ein .NET-Projekt bereits in Ihrem GitHub-Repository verwenden möchten, können Sie diesen Abschnitt überspringen.

Wenn Sie nicht über ein .NET-Projekt verfügen, mit dem Sie arbeiten können, erstellen Sie wie folgt ein neues Projekt auf Ihrem lokalen Computer:

  1. Installieren Sie das .NET 8.0 SDK, oder stellen Sie sicher, dass es installiert ist.
  2. Öffnen Sie ein Terminalfenster auf Ihrem lokalen Computer.
  3. Erstellen Sie ein Projektverzeichnis, und wechseln Sie zu diesem Verzeichnis.
  4. Erstellen Sie eine neue .NET 8-Web-App, indem Sie diese ausführen dotnet new webapp -f net8.0.
  5. Erstellen und ausführen Sie die Anwendung lokal mithilfe von dotnet run.
  6. Wenn die Anwendung gestartet wird, drücken Sie STRG+C, um sie herunterzufahren.
  7. Laden Sie das lokale Projekt mit Ihrem GitHub-Repository hoch, oder verbinden Sie es.

Erstellen einer Pipeline

Wenn Sie über eine Pipeline verfügen, die Sie verwenden möchten, können Sie diesen Abschnitt überspringen. Andernfalls können Sie entweder den YAML-Pipeline-Editor oder den klassischen Editor verwenden, um eine Pipeline wie folgt zu erstellen:

  1. Wählen Sie in Ihrem Azure DevOps-Projekt pipelines aus dem linken Navigationsmenü aus.

  2. Wählen Sie "Neue Pipeline" oder " Pipeline erstellen " aus, wenn diese Pipeline der erste im Projekt ist.

  3. Wählen Sie auf dem Codebildschirm "Wo befindet sich Ihr Code " auf GitHub aus.

  4. Möglicherweise werden Sie zu GitHub weitergeleitet, um sich anzumelden. Geben Sie in diesem Fall Ihre Anmeldeinformationen für GitHub ein.

  5. Wählen Sie auf dem Bildschirm " Repository auswählen " das Repository aus, in dem sich Ihre .NET-App befindet.

  6. Sie werden möglicherweise zu GitHub weitergeleitet, um die Azure Pipelines-App zu installieren. Wählen Sie in diesem Fall Genehmigen & installieren aus.

  1. Wählen Sie auf der Registerkarte " Konfigurieren " die Option " Mehr anzeigen" aus, und wählen Sie dann in der Liste die ASP.NET Core-Pipelinevorlage aus. Diese Vorlage enthält viele der in diesem Artikel beschriebenen Schritte und Einstellungen.

    Sie können auch die Startpipeline auf der Registerkarte " Konfigurieren " auswählen, um mit einer minimalen Pipeline zu beginnen und die Schritte und Einstellungen selbst hinzuzufügen.

  2. Überprüfen Sie auf der Registerkarte " Überprüfen " den YAML-Code. Sie können die Datei für Ihre Anforderungen anpassen. Sie können z. B. einen anderen Agentpool angeben oder eine Aufgabe hinzufügen, um ein anderes .NET SDK zu installieren.

  1. Wählen Sie in Ihrem Azure DevOps-Projekt pipelines aus dem linken Navigationsmenü aus.

  2. Wählen Sie "Neue Pipeline" oder " Pipeline erstellen " aus, wenn diese Pipeline der erste im Projekt ist.

  3. Wählen Sie Ihren Quell-Repositorytyp aus. In diesem Beispiel verwenden Sie GitHub Enterprise Server.

  4. Geben Sie auf dem nächsten Bildschirm die folgenden Informationen ein:

    • Die URL für Ihr GitHub-Konto, z. B https://github.com/myname. .
    • Ihr GitHub-Zugriffstoken (Personal Access Token, PAT).
    • Ein Dienstverbindungsname, z. B my-github. .
  5. Klicken Sie auf Erstellen.

  6. Wählen Sie Ihr GitHub-Repository aus.

  7. Wählen Sie auf der Registerkarte Konfigurieren die Option Mehr anzeigen und dann die ASP.NET Core Pipeline-Vorlage aus der Liste aus. Diese Vorlage enthält viele der in diesem Artikel beschriebenen Schritte und Einstellungen.

  8. Überprüfen Sie den neuen YAML-Pipelinecode. Sie können die YAML-Datei an Ihre Anforderungen anpassen. Sie können z. B. eine Aufgabe hinzufügen, um ein anderes .NET SDK zu installieren oder Ihr Projekt zu testen und zu veröffentlichen.

  1. Wenn Sie so weit sind, wählen Sie Speichern und ausführen aus.

    Screenshot der Schaltfläche

  2. Bearbeiten Sie optional die Commit-Nachricht, und wählen Sie dann "Speichern" aus, und führen Sie sie erneut aus .

  3. Wählen Sie auf der Registerkarte " Zusammenfassung " den Auftrag im Abschnitt "Aufträge " aus, um Ihre Pipeline in Aktion zu sehen.

Sie haben jetzt eine funktionierende Pipeline, die zum Anpassen bereit ist.

Einrichten Ihrer Build-Umgebung

Azure Pipelines verwendet selbst gehostete Agents , um Ihr .NET Core-Projekt zu erstellen. Sie können das .NET Core SDK und die Laufzeit unter Windows, Linux, macOS oder Docker-Agents verwenden. Stellen Sie sicher, dass Sie die erforderliche Version des .NET Core SDKs und der Runtime auf den Agenten installiert haben.

Um eine bestimmte Version des .NET SDK zu installieren, fügen Sie die UseDotNet@2 Aufgabe einer YAML-Pipelinedatei oder der Aufgabe ".NET Core verwenden" im klassischen Editor hinzu.

Hinweis

Für Agents, die auf physischen Systemen ausgeführt werden, ändert die Installation von SDKs und Tools über Ihre Pipeline die Buildumgebung auf dem Host des Agents.

Im folgenden Beispiel wird der YAML-Codeausschnitt .NET SDK 8.0.x installiert:

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

Um ein neueres SDK zu installieren, legen Sie den Satzes performMultiLevelLookup auf true.

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

Sie können den Agentenpool und den Agenten für Ihren Build-Job auswählen. Sie können auch Agents basierend auf ihren Funktionen angeben. Der folgende YAML-Pipelineausschnitt wählt beispielsweise einen Pool und eine Agent-Funktion aus.

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

Sie können Ihre .NET Core-Projekte mithilfe des .NET Core SDK und der Laufzeit für Windows, Linux oder macOS erstellen. Standardmäßig werden Ihre Builds auf von Microsoft gehosteten Agents ausgeführt, sodass Sie keine Infrastruktur einrichten müssen.

Die von Microsoft gehosteten Azure Pipelines-Agents enthalten mehrere vorinstallierte Versionen unterstützter .NET Core-SDKs. Eine vollständige Liste der verfügbaren Images und Konfigurationsbeispiele finden Sie unter microsoft-gehosteten Agents .

Der folgende YAML-Pipelineausschnitt legt Ubuntu OS für den Agentpool fest.

pool:
  vmImage: 'ubuntu-latest' 

Von Microsoft gehostete Agents enthalten keine älteren Versionen des .NET Core SDK und enthalten in der Regel keine Vorabversionen. Wenn Sie diese Versionen des SDK auf von Microsoft gehosteten Agents benötigen, können Sie diese mithilfe der Aufgabe "DotNet verwenden " (UseDotNet@2) installieren.

Der folgende Code installiert z. B. das .NET 5.0.x SDK:

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

Windows-Agents enthalten bereits eine .NET Core-Runtime. Wenn Sie ein neueres SDK installieren möchten, legen Sie performMultiLevelLookup diese Einstellung wie im folgenden Codeausschnitt fest true :

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

Selbstgehostete Agents

Alternativ können Sie selbst gehostete Agents verwenden, um Ihre .NET Core-Projekte zu erstellen. Sie können Linux-, macOS- oder Windows-selbst gehostete Agents einrichten.

Selbst gehostete Agents ermöglichen Folgendes:

  • Vermeiden Sie die Kosten für die Ausführung des UseDotNet@2 Toolinstallationsprogramms.
  • Verringern Sie die Buildzeit, wenn Sie über ein großes Repository verfügen.
  • Führen Sie inkrementelle Builds aus.
  • Verwenden Sie Vorschau- oder private SDKs, die von Microsoft nicht offiziell unterstützt werden.
  • Verwenden Sie SDKs, die nur in Ihrer Unternehmens- oder lokalen Umgebung verfügbar sind.

Weitere Informationen finden Sie unter Selbstgehostete Agenten.

Wiederherstellen von Abhängigkeiten

NuGet-Pakete sind eine Möglichkeit für Ihr Projekt, von Code abhängig zu sein, den Sie nicht erstellen. Sie können NuGet-Pakete und projektspezifische Tools herunterladen, indem Sie den dotnet restore Befehl entweder über die .NET Core-Aufgabe (DotNetCoreCLI@2) oder als Skript in Ihrer Pipeline ausführen. Der dotnet restore Befehl verwendet das mit .NET Core SDK verpackteNuGet.exeund kann nur Pakete wiederherstellen, die in den .NET Core-Projekt *.csproj-Dateien angegeben sind.

Sie können die .NET Core (DotNetCoreCLI@2)-Aufgabe verwenden, um NuGet-Pakete aus Azure Artifacts, NuGet.org oder einem anderen authentifizierten externen oder internen NuGet-Repository herunterzuladen und wiederherzustellen. Wenn sich der NuGet-Feed im selben Projekt wie Ihre Pipeline befindet, müssen Sie sich nicht authentifizieren. Weitere Informationen finden Sie unter .NET Core-Aufgabe (DotNetCoreCLI@2).

Wenn Sie von Microsoft gehostete Agenten verwenden, erhalten Sie bei jedem Ausführen eines Builds eine neue Maschine, die die Pakete bei jeder Ausführung wiederherstellt. Die Wiederherstellung kann sehr lange dauern. Um dieses Problem zu beheben, verwenden Sie Azure Artifacts oder einen selbst gehosteten Agent , um den Paketcache zu nutzen.

Die folgende Pipeline verwendet die DotNetCoreCLI@2 Aufgabe zum Wiederherstellen eines Azure Artifact-Feeds.

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)'

In .NET Core SDK, Version 2.0 und höher, werden Pakete beim Ausführen von Befehlen wie z dotnet build. B. automatisch wiederhergestellt. Sie müssen weiterhin die .NET Core (DotNetCoreCLI@2)-Aufgabe verwenden, um Pakete wiederherzustellen, wenn Sie einen authentifizierten Feed verwenden.

Verwalten Sie die Anmeldeinformationen für einen authentifizierten Feed, indem Sie eine NuGet-Dienstverbindung in Project Settings>Pipelines>Service-Verbindungen erstellen. Weitere Informationen zu NuGet-Dienstverbindungen finden Sie unter Veröffentlichen von NuGet-Paketen mit Azure-Pipelines.

Wiederherstellen von Paketen aus NuGet.org

Aktualisieren Sie Die Pipeline wie folgt, um Pakete aus NuGet.org wie folgt wiederherzustellen.

Sie können der Pipeline den Wiederherstellungsbefehl hinzufügen, indem Sie den YAML-Code direkt oder mithilfe des Aufgaben-Assistenten bearbeiten.

Fügen Sie die .NET Core (DotNetCoreCLI@2)-Aufgabe direkt hinzu, indem Sie den folgenden Codeausschnitt in die azure-pipelines.yml Datei einfügen, bevor Sie Die Buildaufgaben ausführen.

steps:
- task: DotNetCoreCLI@2
  displayName: Restore
  inputs:
    command: restore
    projects: '**/*.csproj'
    feedsToUse: select

So verwenden Sie den Aufgabenassistenten:

  1. Gehen Sie zu der Stelle in der YAML-Datei, an der Sie die Aufgabe einfügen möchten.
  2. Wählen Sie .NET Core aus dem Aufgabenkatalog aus.
  3. Wählen Sie auf dem Konfigurationsbildschirm die Option "Wiederherstellen " aus der Dropdownliste "Befehl" aus.
  4. Geben Sie im Feld "Pfad zu Projekt(en) oder Projektmappen " den Pfad zu Ihren *.csproj-Dateien ein. Sie können die Wildcard **/*.csproj für alle *.csproj-Dateien in allen Unterordnern verwenden.
  5. Stellen Sie sicher, dass Feeds, die ich hier auswählte, und Pakete aus NuGet.org verwenden ausgewählt sind, damit Feeds hinzugefügt werden.
  6. Wählen Sie Hinzufügen.
  7. Wählen Sie "Überprüfen und speichern" und dann " Speichern" aus, um die Änderung zu übernehmen.

Pakete aus einem externen Feed wiederherstellen

Um ein externes NuGet-Repository anzugeben, platzieren Sie die URL in einer NuGet.config Datei in Ihrem Repository. Stellen Sie sicher, dass ein benutzerdefinierter Feed in Ihrer NuGet.config-Datei angegeben ist und dass Anmeldeinformationen in einer NuGet-Dienstverbindung angegeben sind.

Um Pakete aus einem externen Feed wiederherzustellen, fügen Sie die restore Aufgabe wie im vorherigen Abschnitt beschrieben hinzu, ändern Sie jedoch die Konfigurationseinstellungen wie folgt:

Fügen Sie die .NET Core (DotNetCoreCLI@2)-Aufgabe direkt hinzu, indem Sie den folgenden Codeausschnitt in die azure-pipelines.yml Datei einfügen, bevor Sie Die Buildaufgaben ausführen. Ersetzen Sie den <NuGet service connection> Namen Ihrer Dienstverbindung.

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

So verwenden Sie den Aufgabenassistenten:

  1. Fügen Sie die .NET Core-Aufgabe hinzu, und wählen Sie die Wiederherstellung auf dem Konfigurationsbildschirm wie im vorherigen Verfahren aus.
  2. Wenn Feeds hinzugefügt werden sollen, wählen Sie Feeds in meinem NuGet.configaus.
  3. Geben Sie unter "Pfad zu NuGet.config" den Pfad zu Ihrer NuGet.config-Datei relativ zum Stammverzeichnis Ihres Repositorys ein. Sie können die Auslassungspunkte auswählen ... neben dem Feld, zu dem Sie navigieren möchten, und die Position auswählen.
  4. Wählen Sie unter "Anmeldeinformationen für Feeds außerhalb dieser Organisation/Sammlung" Anmeldeinformationen aus, die für externe Registrierungen in der ausgewählten NuGet.config Datei verwendet werden sollen. Bei Feeds in derselben Organisation können Sie dieses Feld leer lassen. Die Anmeldeinformationen des Builds werden automatisch verwendet.

Wiederherstellen von Paketen für .NET Framework-Projekte

Wenn Sie auch über ein Microsoft .NET Framework-Projekt in Ihrer Lösung verfügen oder package.json verwenden, um Ihre Abhängigkeiten anzugeben, verwenden Sie die NuGetCommand@2 Aufgabe, um diese Abhängigkeiten wiederherzustellen.

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

Hinweis

Für Ubuntu 24.04 oder höher müssen Sie die NuGetAuthenticate-Aufgabe anstelle der NuGetCommand@2 Aufgabe mit der .NET CLI verwenden. Weitere Informationen finden Sie unter Support für neuere gehostete Ubuntu-Bilder.

Erstellen Ihres Projekts

Erstellen Sie Ihr .NET Core-Projekt, indem Sie den dotnet build Befehl ausführen. Sie können den Befehl zu Ihrer Pipeline hinzufügen, indem Sie die .NET Core-Aufgabe (DotNetCoreCLI@2) oder als Befehlszeilenskript verwenden.

Verwenden der .NET Core-Aufgabe

Sie können eine Buildaufgabe mit dem YAML-Pipeline-Editor hinzufügen, indem Sie die Datei direkt bearbeiten oder den Aufgaben-Assistenten verwenden.

Fügen Sie die .NET Core (DotNetCoreCLI@2)-Aufgabe direkt hinzu, indem Sie den folgenden Codeausschnitt einfügen. Aktualisieren Sie die arguments Anforderungen entsprechend.

steps:
- task: DotNetCoreCLI@2
  displayName: Build
  inputs:
    command: build
    projects: '**/*.csproj'
    arguments: '--configuration $(buildConfiguration)'

So verwenden Sie den Aufgabenassistenten:

  1. Gehen Sie zu der Stelle in der YAML-Datei, an der Sie die Aufgabe einfügen möchten.
  2. Wählen Sie die .NET Core ()-Aufgabe ausDotNetCoreCLI@2.
  3. Wählen Sie "Build" aus der Dropdownliste "Befehl" aus.
  4. Geben Sie im Feld "Pfad zu Projekt(en) oder Projektmappen " den Pfad zu Ihren *.csproj-Dateien ein. Sie können die Wildcard **/*.csproj für alle *.csproj-Dateien in allen Unterordnern verwenden.
  5. Wählen Sie Hinzufügen.
  6. Wählen Sie Speichern, um die Änderung zu committen.

Erstellen von .NET Core mit einem Befehlszeilenskript

Sie können auch mithilfe eines Befehlszeilenskripts erstellen.

Um eine Build-Befehlszeile hinzuzufügen, indem Sie die YAML-Datei direkt bearbeiten, fügen Sie den folgenden Code hinzu:

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

Sie können auch den Aufgaben-Assistenten verwenden, um die Befehlszeilenaufgabe hinzuzufügen.

  1. Gehen Sie zu der Stelle in der YAML-Datei, an der Sie die Aufgabe einfügen möchten.
  2. Wählen Sie die Befehlszeilenaufgabe (CmdLine@2) aus der Liste aus.
  3. Geben Sie im Feld "Skript " den dotnet build Befehl mit Parametern ein. Beispiel: dotnet build --configuration $(buildConfiguration).
  4. Geben Sie unter "Erweitertes>Arbeitsverzeichnis" den Pfad zur Datei "*.csproj " als Arbeitsverzeichnis ein. Wenn Sie es leer lassen, wird das Arbeitsverzeichnis standardmäßig auf $(Build.SourcesDirectory).
  5. Wählen Sie Hinzufügen.
  6. Wählen Sie Speichern, um die Änderung zu committen.

Hinzufügen weiterer .NET SDK-Befehle zu Ihrer Pipeline

Sie können Ihrer Pipeline weitere .NET SDK-Befehle hinzufügen, indem Sie die .NET Core-Aufgabe (DotNetCoreCLI@2) oder als Skripts verwenden.

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

Mit der Aufgabe .NET Core (DotNetCoreCLI@2) können Sie Ihrer Pipeline problemlos .NET CLI-Befehle hinzufügen. Sie können .NET Core (DotNetCoreCLI@2)-Aufgaben hinzufügen, indem Sie Ihre YAML-Datei bearbeiten oder den klassischen Editor verwenden.

Führen Sie die folgenden Schritte aus, um einen .NET Core-Befehl mithilfe des Aufgaben-Assistenten im YAML-Pipeline-Editor hinzuzufügen:

  1. Gehen Sie zu der Stelle in der YAML-Datei, an der Sie die Aufgabe einfügen möchten.
  2. Wählen Sie .NET Core aus dem Aufgabenkatalog aus.
  3. Wählen Sie den Befehl aus, den Sie in der Dropdownliste im Befehlsfeld ausführen möchten.
  4. Konfigurieren Sie alle erforderlichen Optionen.
  5. Wählen Sie Hinzufügen.
  6. Wählen Sie Speichern, um die Änderung zu committen.

Hinzufügen eines .NET Core CLI-Befehls in einem Skript

Sie können einen .NET Core CLI-Befehl als eine script in Ihrer azure-pipelines.yml-Datei hinzufügen. Beispiel:


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

Installieren eines Tools

Um ein globales .NET Core-Tool wie dotnetsay in einem Build unter Windows zu installieren, fügen Sie eine .NET Core-Aufgabe hinzu, und legen Sie die folgenden Eigenschaften in der Konfiguration fest:

  • Befehl: benutzerdefiniert
  • Pfad zu Projekten: Leer lassen
  • Benutzerdefinierter Befehl: tool
  • Argumente: install -g dotnetsay

Um das Tool auszuführen, fügen Sie eine Befehlszeilenaufgabe hinzu, und geben Sie dotnetsay das Feld "Skript " ein.

Ausführen der Tests

Wenn Sie Testprojekte in Ihrem Repository haben, können Sie die .NET Core (DotNetCoreCLI@2)-Aufgabe verwenden, um Komponententests mithilfe von Testframeworks wie MSTest, xUnit und NUnit auszuführen. Das Testprojekt muss auf Microsoft.NET.Test.SDK, Version 15.8.0 oder höher, verweisen.

Testergebnisse werden automatisch im Dienst veröffentlicht und stehen Ihnen in der Buildzusammenfassung zur Verfügung. Sie können die Testergebnisse verwenden, um fehlgeschlagene Tests zu beheben und die Testdauer zu analysieren.

Um Ihrer Pipeline eine Testaufgabe hinzuzufügen, fügen Sie der azure-pipelines.yml Datei den folgenden Codeausschnitt hinzu:

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

Wenn Sie den Aufgaben-Assistenten verwenden, um die .NET Core (DotNetCoreCLI@2)-Aufgabe hinzuzufügen, legen Sie die folgenden Eigenschaften fest:

  • Befehl: Testen
  • Pfad zu Projekten: Festlegen auf die Testprojekte in Ihrer Lösung
  • Argumente: --configuration $(BuildConfiguration)

Alternativ können Sie den dotnet test Befehl mit einem bestimmten Logger ausführen und dann die PublishTestResults@2 Aufgabe verwenden:

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

Sammeln von Code Coverage

Wenn Sie auf der Windows-Plattform aufbauen, können Sie Codeabdeckungsmetriken mithilfe des integrierten Abdeckungsdatensammlers sammeln. Das Testprojekt muss auf Microsoft.NET.Test.SDK, Version 15.8.0 oder höher, verweisen.

Wenn Sie die .NET Core (DotNetCoreCLI@2)-Aufgabe zum Ausführen von Tests verwenden, werden Abdeckungsdaten automatisch auf dem Server veröffentlicht. Sie können die *.coverage-Datei aus der Buildzusammenfassung herunterladen, um sie in Visual Studio anzuzeigen.

Um die Codeabdeckung zu sammeln, fügen Sie das --collect "Code Coverage" Argument hinzu, wenn Sie der Pipeline die Testaufgabe hinzufügen.

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

Wenn Sie den Aufgaben-Assistenten verwenden, um die .NET Core (DotNetCoreCLI@2)-Aufgabe hinzuzufügen, legen Sie die folgenden Eigenschaften fest:

  • Befehl: Testen
  • Pfad zu Projekten: Festlegen auf die Testprojekte in Ihrer Lösung
  • Argumente: --configuration $(BuildConfiguration) --collect "Code Coverage"

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

Verwenden Sie alternativ den folgenden Code, um Codeabdeckungsergebnisse mithilfe des dotnet test Befehls mit einem bestimmten Logger zu sammeln und dann die PublishTestResults@2 Aufgabe auszuführen:

steps:
# ...
# do this after your tests 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 auf Linux oder macOS aufbauen, können Sie Coverlet oder ein ähnliches Tool verwenden, um Codeabdeckungsmetriken zu sammeln.

Sie können Codeabdeckungsergebnisse mit der Aufgabe "Codeabdeckungsergebnisse veröffentlichen" (PublishCodeCoverageResults@2) auf dem Server veröffentlichen. Sie müssen das Abdeckungstool konfigurieren, um Ergebnisse im Cobertura- oder JaCoCo-Abdeckungsformat zu generieren.

So führen Sie Tests aus, und veröffentlichen Sie die Codeabdeckung mit Coverlet:

  1. Fügen Sie einen Verweis auf das NuGet-Paket coverlet.collector hinzu.
  2. Fügen Sie der datei azure-pipelines.yml den folgenden Codeausschnitt hinzu:
- 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: '<test project directory>'
  
- task: PublishCodeCoverageResults@2
  displayName: 'Publish code coverage report'
  inputs:
    codeCoverageTool: 'Cobertura'
    summaryFileLocation: '$(Agent.TempDirectory)/**/coverage.cobertura.xml'

Verpacken und Übermitteln von Code

Um Die Buildausgabe zu packen und bereitzustellen, können Sie:

  • Veröffentlichen Sie Ihre Buildartefakte in Azure Pipelines.
  • Erstellen Sie ein NuGet-Paket, und veröffentlichen Sie es in Ihrem NuGet-Feed.
  • Veröffentlichen Sie Ihr NuGet-Paket in Azure Artifacts.
  • Erstellen Sie ein ZIP-Archiv für die Bereitstellung in einer Web-App.
  • Veröffentlichen Sie Symbole auf einem Azure Artifacts-Symbolserver oder einer Dateifreigabe.

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

Veröffentlichen von Artefakten in Azure Pipelines

Führen Sie die folgenden Schritte aus, um die Ausgabe Ihres .NET-Builds in Ihrer Pipeline zu veröffentlichen.

  1. Führen Sie dotnet publish --output $(Build.ArtifactStagingDirectory) die .NET CLI aus, oder fügen Sie die .NET Core (DotNetCoreCLI@2)-Aufgabe mit dem Befehl zum Veröffentlichen hinzu.
  2. Veröffentlichen Sie das Artefakt mithilfe der Aufgabe Publish Pipeline Artifact (PublishPipelineArtifact@1). Diese Aufgabe lädt alle Dateien $(Build.ArtifactStagingDirectory) als Artefakt Ihres Builds hoch.

Fügen Sie ihrer azure-pipelines.yml Datei den folgenden Code hinzu:

steps:

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

- task: PublishPipelineArtifact@1
  inputs:
    targetPath: '$(Build.ArtifactStagingDirectory)' 
    artifactName: 'myWebsite'

Um vor dem Veröffentlichen weitere Dateien in das Build-Verzeichnis zu kopieren, verwenden Sie die Aufgabe Dateien kopieren (CopyFile@2).

Hinweis

Die publishWebProjects Eingabe in der .NET Core (DotNetCoreCLI@2)-Aufgabe ist standardmäßig festgelegt true und veröffentlicht alle Webprojekte in Ihrem Repository. Weitere Informationen finden Sie im GitHub-Repository "azure-pipelines-tasks ".

Führen Sie die folgenden Aufgaben aus, um die Ausgabe Ihres .NET-Builds in Ihrer Pipeline zu veröffentlichen:

  1. Führen Sie dotnet publish --output $(Build.ArtifactStagingDirectory) die .NET CLI aus, oder fügen Sie die .NET Core (DotNetCoreCLI@2)-Aufgabe mit dem Befehl zum Veröffentlichen hinzu.
  2. Veröffentlichen Sie das Artefakt mit der Aufgabe Build-Artefakt veröffentlichen (PublishBuildArtifacts@1).

Der folgende azure-pipelines.yml Code veröffentlicht auch Ihre Buildartefakte als ZIP-Datei. Die PublishBuildArtifacts@1 Aufgabe lädt alle Dateien $(Build.ArtifactStagingDirectory) als Artefakt Ihres Builds hoch.

steps:

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

- task: PublishBuildArtifacts@1
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
    ArtifactName: 'drop'

Weitere Informationen finden Sie unter Build-Artefakte veröffentlichen und herunterladen.

Veröffentlichen in einem NuGet-Feed

Um ein NuGet-Paket zu erstellen und in Ihrem NuGet-Feed zu veröffentlichen, fügen Sie der azure-pipelines.yml Datei den folgenden Codeausschnitt hinzu:

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

Hinweis

Die NuGetAuthenticate@1 Aufgabe unterstützt keine NuGet-API-Schlüsselauthentifizierung. Wenn Sie einen NuGet-API-Schlüssel verwenden, verwenden Sie die Aufgabe mit dem NuGetCommand@2command Eingabesatz push und dem --api-key Argument. Beispiel: dotnet nuget push --api-key $(NuGetApiKey).

Weitere Informationen zum Versionsverwaltungs- und Veröffentlichen von NuGet-Paketen finden Sie unter Veröffentlichen von NuGet-Paketen mit Azure-Pipelines.

Veröffentlichen eines NuGet-Pakets in Azure Artifacts

Sie können Ihre NuGet-Pakete in Ihrem Azure Artifacts-Feed veröffentlichen, indem Sie die NuGetCommand@2 Aufgabe verwenden. Weitere Informationen finden Sie unter Veröffentlichen von NuGet-Paketen mit Azure-Pipelines.

Veröffentlichen eines ZIP-Dateiarchivs in einer Web-App

Um ein ZIP-Dateiarchiv zu erstellen, das für die Veröffentlichung in einer Web-App bereit ist, fügen Sie dem azure-pipelines.yml den folgenden Codeausschnitt hinzu. Führen Sie diese Aufgabe nach dem Erstellen Ihrer App in den meisten Fällen am Ende der Pipeline aus. Führen Sie diese Aufgabe z. B. aus, bevor Sie sie in einer Azure-Web-App unter Windows bereitstellen.

steps:
# ...
- 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.

Veröffentlichen von Symbolen

Sie können die PublishSymbols@2 Aufgabe verwenden, um Symbole auf einem Azure Artifacts-Symbolserver oder einer Dateifreigabe zu veröffentlichen. Weitere Informationen finden Sie unter Symbole 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>'

Um den klassischen Editor zu verwenden, fügen Sie der Pipeline die Indexquellen hinzu und veröffentlichen Sie die Symbolaufgabe .

Problembehandlung

Wenn Ihr Projekt erfolgreich auf Ihrem lokalen Computer, aber nicht in Azure Pipelines erstellt wird, untersuchen Sie die folgenden potenziellen Ursachen und Korrekturmaßnahmen.

  • Vorabversionen des .NET Core SDK werden nicht auf von Microsoft gehosteten Agents installiert, und das Rollout einer neuen Version des SDK für alle Azure Pipelines-Rechenzentren kann einige Wochen dauern. Anstatt auf den Abschluss eines Rollouts zu warten, können Sie die .NET Core-Aufgabe verwenden, um die gewünschte .NET Core SDK-Version auf microsoft-gehosteten Agents zu installieren.
  • Eine neue Version des .NET Core SDK oder Visual Studio könnte den Build unterbrechen, z. B. wenn sie eine neuere Version oder ein neues Feature des NuGet-Tools enthält. Stellen Sie sicher, dass die .NET Core SDK-Versionen und -Laufzeit auf Ihrem Entwicklungscomputer mit dem Pipeline-Agent übereinstimmen.

    Sie können ein dotnet --version Befehlszeilenskript in Ihre Pipeline einfügen, um die Version des .NET Core SDK zu drucken. Verwenden Sie entweder das .NET Core Tool Installer , um dieselbe Version auf dem Agent bereitzustellen, oder aktualisieren Sie Ihre Projekte und Entwicklungscomputer auf die Pipelineversion des .NET Core SDK.

  • Ihre Builds können aufgrund von Verbindungsproblemen unterbrochen werden, wenn Sie Pakete aus NuGet.org wiederherstellen. NuGet.org möglicherweise Probleme haben, oder es können Netzwerkprobleme zwischen dem Azure-Rechenzentrum und NuGet.org auftreten. Sie können untersuchen, ob die Verwendung von Azure Artifacts mit upstream-Quellen zum Zwischenspeichern der Pakete die Zuverlässigkeit Ihrer Builds verbessert.

    Die Anmeldeinformationen der Pipeline werden automatisch verwendet, um eine Verbindung mit Azure Artifacts herzustellen. 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.

  • Möglicherweise verwenden Sie eine Logik in Visual Studio, die in Ihrer Pipeline nicht codiert ist. Azure Pipelines führt jeden Befehl in einer Aufgabe sequenziell in einem neuen Prozess aus. Überprüfen Sie die Protokolle aus dem Pipelinebuild, um die genauen Befehle anzuzeigen, die im Build ausgeführt wurden. Um das Problem zu finden, wiederholen Sie dieselben Befehle in derselben Reihenfolge auf Ihrem Entwicklungscomputer.

  • Wenn Sie über eine gemischte Lösung verfügen, die einige .NET Core-Projekte und einige .NET Framework-Projekte enthält, verwenden Sie die NuGet-Aufgabe zum Wiederherstellen von Paketen, die in den packages.config-Dateien angegeben sind. Fügen Sie die Aufgabe MSBuild oder Visual Studio-Build hinzu, um die .NET Framework-Projekte zu erstellen.