Entwickeln, Testen und Bereitstellen von .NET Core-Apps

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

Verwenden Sie eine Pipeline, um Ihre .NET Core-Projekte automatisch zu erstellen und zu testen. Erfahren Sie, wie Sie die folgenden Aufgaben ausführen:

• Richten Sie Ihre Buildumgebung mit von Microsoft gehosteten oder selbstgehosteten Agents ein.
• Stellen Sie Abhängigkeiten wieder her, erstellen Sie Ihr Projekt, und testen Sie sie mit der .NET Core CLI-Aufgabe oder einem Skript.
• Verwenden Sie die Aufgabe Code Coverage veröffentlichen , um Code Coverage-Ergebnisse zu veröffentlichen.
• Packen und übermitteln Sie Ihren Code mit der .NET Core-CLI-Aufgabe und der Aufgabe Buildartefakte veröffentlichen.
• Veröffentlichen sie in einem NuGet-Feed.
• Stellen Sie Ihre Web-App in Azure bereit.

Hinweis

Hilfe zu .NET Framework Projekten finden Sie unter Erstellen ASP.NET Apps mit .NET Framework.

Erstellen Ihrer ersten Pipeline

Sind Sie noch nicht in Azure Pipelines? Wenn ja, sollten Sie zuerst den folgenden Abschnitt ausprobieren.

Erstellen eines .NET-Projekts.

Wenn Sie nicht über ein .NET-Projekt verfügen, mit dem Sie arbeiten können, erstellen Sie ein neues Projekt, und laden Sie Ihren Code in Ihr GitHub-Repository oder Azure Repos hoch. Installieren Sie zunächst das neueste .NET 6.0 SDK.

Erstellen Sie eine neue .NET 6-Webapp.

dotnet new webapp -f net6.0

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

dotnet run

---

Code hochladen

Laden Sie Ihren Code in die neue Web-App GitHub oder Azure Repos hoch:

• Erstellen Sie ein neues Git-Repository in Azure Repos.
• Erstellen Sie ein neues GitHub-Repository.

Anmelden bei Azure Pipelines

Melden Sie sich bei Azure Pipelines an. Nach der Anmeldung wechselt Ihr Browser zu https://dev.azure.com/my-organization-name und zeigt Ihr Azure DevOps-Dashboard an.

Erstellen Sie in Ihrer ausgewählten Organisation ein Projekt. Sollten in Ihrer Organisation noch keine Projekte vorhanden sein, wird der Bildschirm Erstellen Sie als ersten Schritt ein Projekt. angezeigt. Wählen Sie andernfalls in der rechten oberen Ecke des Dashboards die Schaltfläche Neues Projekt aus.

Erstellen der Pipeline

1. Melden Sie sich bei Ihrem Azure DevOps-organization an, und wechseln Sie zu Ihrem Projekt.

2. Navigieren Sie zu Pipelines, und wählen Sie Neue Pipeline aus.

3. Führen Sie die Schritte des Assistenten aus. Dabei wählen Sie zuerst GitHub als Speicherort Ihres Quellcodes aus.

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

5. Wenn die Liste der Repositorys angezeigt wird, wählen Sie Ihr Repository aus.

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

Wählen Sie bei Anzeige der Registerkarte Konfigurieren die Option ASP.NET Core aus.

1. Untersuchen Sie Ihre neue Pipeline, um zu sehen, was YAML tut. Wenn Sie so weit sind, wählen Sie Speichern und ausführen aus.

   

2. Committen Sie eine neue Datei azure-pipelines.yml in Ihr Repository. Nachdem Sie mit der Nachricht zufrieden sind, wählen Sie Speichern und erneut ausführen aus.

   Wenn Sie Ihre Pipeline in Aktion watch möchten, wählen Sie den Buildauftrag aus.

   Da Ihr Code für die ASP.NET Core-Vorlage geeignet schien, haben wir die Pipeline automatisch für Sie erstellt.

   Sie haben jetzt eine funktionierende YAML-Pipeline (azure-pipelines.yml) in Ihrem Repository, die Sie anpassen können!

3. Wenn Sie bereit sind, Änderungen an Ihrer Pipeline vorzunehmen, wählen Sie sie auf der Seite Pipelines aus, und bearbeiten Sie dann die azure-pipelines.yml Datei.

Lesen Sie weiter, um einige der gängigsten Möglichkeiten zum Anpassen Ihrer Pipeline zu erfahren.

Buildumgebung

Verwenden Sie Azure Pipelines, um Ihre .NET Core-Projekte zu erstellen. Erstellen Sie Ihre Projekte unter Windows, Linux oder macOS, ohne die Infrastruktur einrichten zu müssen. Die von Microsoft gehosteten Agents in Azure Pipelines enthalten mehrere vorinstallierte Versionen der .NET Core-SDKs.

Ubuntu ist hier in der YAML-Datei festgelegt.

pool:
  vmImage: 'ubuntu-latest' 

Unter Von Microsoft gehostete Agents finden Sie eine vollständige Liste der Images und einen Pool für weitere Beispiele.

Die von Microsoft gehosteten Agents enthalten keine älteren Versionen des .NET Core SDK. Außerdem enthalten sie in der Regel keine Vorabversionen. Wenn Sie diese Art von SDKs für von Microsoft gehostete Agents benötigen, fügen Sie der YAML-Datei die UseDotNet@2 Aufgabe hinzu.

Um das 6.0.x SDK für die Erstellung zu installieren, fügen Sie den folgenden Codeausschnitt hinzu:

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

Windows-Agents enthalten bereits eine .NET Core-Runtime. Um ein neueres SDK zu installieren, legen Sie im folgenden Codeausschnitt auf true festperformMultiLevelLookup:

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

Tipp

Um die Kosten für die Ausführung des Toolinstallationsprogramms zu sparen, können Sie einen selbstgehosteten Agent einrichten. Siehe Linux, macOS oder Windows. Sie können auch selbstgehostete Agents verwenden, um zusätzliche Zeit zu sparen, wenn Sie über ein großes Repository verfügen oder inkrementelle Builds ausführen. Ein selbstgehostete Agent kann Ihnen auch bei der Verwendung der Vorschau- oder privaten SDKs helfen, die nicht offiziell von Azure DevOps unterstützt werden oder nur in Ihren Unternehmens- oder lokalen Umgebungen verfügbar sind.

Wiederherstellen von Abhängigkeiten

NuGet ist eine beliebte Methode, um von Code abhängig zu sein, den Sie nicht erstellen. Sie können NuGet-Pakete und projektspezifische Tools herunterladen, die in der Projektdatei angegeben sind, indem Sie den dotnet restore Befehl entweder über die .NET Core-Aufgabe oder direkt in einem Skript in Ihrer Pipeline ausführen.

Sie können NuGet-Pakete 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 im selben Projekt wie Ihre Pipeline befindet, müssen Sie sich nicht authentifizieren.

Diese Pipeline verwendet einen Artefaktfeed für dotnet restore in der .NET Core-CLI-Aufgabe.

trigger:
- main

pool:
  vmImage: 'windows-latest'

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

dotnet restore intern verwendet eine Version von NuGet.exe , die mit dem .NET Core SDK gepackt ist. dotnet restore kann nur Pakete wiederherstellen, die in den .NET Core-Projektdateien .csproj angegeben sind. Wenn Sie auch ein Microsoft .NET Framework-Projekt in Ihrer Projektmappe haben oder zum Angeben Ihrer Abhängigkeiten verwendenpackage.json, verwenden Sie den NuGet-Task, um diese Abhängigkeiten wiederherzustellen.

In .NET Core SDK Version 2.0 und höher werden Pakete automatisch wiederhergestellt, wenn andere Befehle wie dotnet buildausgeführt werden. Möglicherweise müssen Sie jedoch weiterhin die .NET Core-Aufgabe verwenden, um Pakete wiederherzustellen, wenn Sie einen authentifizierten Feed verwenden.

Ihre Builds können manchmal aufgrund von Verbindungsproblemen fehlschlagen, wenn Sie Pakete aus NuGet.org wiederherstellen. Sie können Azure Artifacts mit Upstream Quellen verwenden und die Pakete zwischenspeichern. Die Anmeldeinformationen der Pipeline werden automatisch verwendet, wenn eine Verbindung mit Azure Artifacts hergestellt wird. Diese Anmeldeinformationen werden in der Regel vom Project Collection Build Service-Konto abgeleitet.

Wenn Sie ein NuGet-Repository angeben möchten, speichern Sie die URLs in einer NuGet.config Datei in Ihrem Repository. Wenn Ihr Feed authentifiziert ist, verwalten Sie seine Anmeldeinformationen, indem Sie eine NuGet-Dienstverbindung auf der Registerkarte Dienste unter Projekteinstellungen erstellen.

Wenn Sie von Microsoft gehostete Agents verwenden, erhalten Sie jedes Mal einen neuen Computer, wenn Sie einen Build ausführen, was bedeutet, dass die Pakete jedes Mal wiederhergestellt werden. Die Wiederherstellung kann viel Zeit in Anspruch nehmen. Um dies zu verringern, können Sie entweder Azure Artifacts oder einen selbstgehosteten Agent mit dem Vorteil der Verwendung des Paketcaches verwenden.

Verwenden Sie die folgende .NET Core-Aufgabe , um Pakete aus einem externen benutzerdefinierten 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>
# ...

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

Erstellen Ihres Projekts

Sie erstellen Ihr .NET Core-Projekt, indem Sie den dotnet build Befehl in Ihrer Pipeline ausführen oder den .NET Core-Task verwenden.

Um Ihr Projekt mit der .NET Core-Aufgabe zu erstellen, fügen Sie der azure-pipelines.yml Datei den folgenden Codeausschnitt hinzu:

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

Sie können jeden benutzerdefinierten dotnet-Befehl in Ihrer Pipeline ausführen. Das folgende Beispiel zeigt, wie Sie ein globales .NET-Tool , dotnetsay, installieren und verwenden:

steps:
- task: DotNetCoreCLI@2
  displayName: 'Install dotnetsay'
  inputs:
    command: custom
    custom: tool
    arguments: 'install -g dotnetsay'

Ausführen der Tests

Wenn Sie Testprojekte in Ihrem Repository haben, verwenden Sie die .NET Core-Aufgabe , 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. 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.

Fügen Sie der azure-pipelines.yml Datei den folgenden Codeausschnitt hinzu:

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

Alternativ können Sie den dotnet test Befehl mit einer bestimmten Protokollierung 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 auf der Windows-Plattform aufbauen, können Code Coverage-Metriken mithilfe des integrierten Abdeckungsdatensammlers erfasst werden. Das Testprojekt muss auf Microsoft.NET.Test.SDK Version 15.8.0 oder höher verweisen. Wenn Sie die .NET Core-Aufgabe zum Ausführen von Tests verwenden, werden die Abdeckungsdaten automatisch auf dem Server veröffentlicht. Die COVERAGE-Datei kann aus der Buildzusammenfassung heruntergeladen werden, um sie in Visual Studio anzuzeigen.

Fügen Sie der azure-pipelines.yml Datei den folgenden Codeausschnitt 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"'

Wenn Sie den dotnet test Befehl ausführen möchten, geben Sie die Testergebnisprotokollierungs- und Abdeckungsoptionen 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 unter Linux oder macOS bauen, können Sie Coverlet oder ein ähnliches Tool verwenden, um Code Coverage-Metriken zu sammeln.

Sie können Code Coverage-Ergebnisse auf dem Server mit der Aufgabe Code Coverage Results veröffentlichen 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 coverlet.msbuild NuGet-Paket in Ihren Testprojekten für .NET-Projekte unter .NET 5 hinzu. Fügen Sie für .NET 5 einen Verweis auf das coverlet.collector NuGet-Paket hinzu.
• Fügen Sie der azure-pipelines.yml Datei den folgenden Codeausschnitt hinzu:

.NET >= 5

- task: UseDotNet@2
  inputs:
    version: '6.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'

.NET < 5

- 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-library/*.csproj' # update with your test project directory

- task: PublishCodeCoverageResults@1
  displayName: 'Publish code coverage report'
  inputs:
    codeCoverageTool: 'Cobertura'
    summaryFileLocation: '$(Agent.TempDirectory)/**/coverage.cobertura.xml'

Paketieren und Bereitstellen ihres Codes

Laden Sie die Buildausgabe in Azure Pipelines hoch. Sie können ein NuGet-Paket erstellen und veröffentlichen oder die Buildausgabe in eine .zip Datei packen, die in einer Webanwendung bereitgestellt werden soll.

Veröffentlichen von Artefakten in Azure Pipelines

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

• Führen Sie dotnet publish --output $(Build.ArtifactStagingDirectory) die CLI aus, oder fügen Sie den DotNetCoreCLI@2 Task mit dem Befehl veröffentlichen hinzu.
• Veröffentlichen Sie das Artefakt mithilfe des Artefakts veröffentlichen.

Fügen Sie der azure-pipelines.yml Datei den folgenden Codeausschnitt hinzu:

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: 'myWebsiteName'

Hinweis

Die dotNetCoreCLI@2 Aufgabe verfügt über eine publishWebProjects Eingabe, die standardmäßig auf true festgelegt ist. Diese Aufgabe veröffentlicht standardmäßig alle Webprojekte in Ihrem Repository. Weitere Hilfe und Informationen finden Sie unter Open Source Task auf GitHub.

Um weitere Dateien vor der Veröffentlichung in das Verzeichnis erstellen zu kopieren, verwenden Sie Hilfsprogramm: Kopieren von Dateien.

Veröffentlichen in einem NuGet-Feed

Um ein NuGet-Paket zu erstellen und zu veröffentlichen, fügen Sie den folgenden Codeausschnitt 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@0
  input:
    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 Veröffentlichung von NuGet-Paketen finden Sie unter Veröffentlichen in NuGet-Feeds.

Bereitstellen einer Web-App

Fügen Sie den folgenden Codeausschnitt hinzu, um ein .zip-Dateiarchiv zu erstellen, das für die Veröffentlichung in einer Web-App bereit ist:

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-Apps Bereitstellung.

Erstellen eines Images und Pushen an die Containerregistrierung

Für Ihre App können Sie auch ein Image erstellen und an eine Containerregistrierung pushen.

Problembehandlung

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

• Vorabversionen des .NET Core SDK werden nicht auf von Microsoft gehosteten Agents installiert. Nach der Veröffentlichung einer neuen Version des .NET Core SDK kann es einige Wochen dauern, bis das Rollout in allen Azure Pipelines-Rechenzentren erfolgt. Sie müssen nicht warten, bis dieser Rollout abgeschlossen ist. Sie können den .NET Core-Toolinstaller verwenden, um die gewünschte Version des .NET Core SDK auf von Microsoft gehosteten Agents zu installieren.

• Ü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 eine 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 als Teil des Builds ausgeführt wurden. Wiederholen Sie dieselben Befehle in der gleichen 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 den MSBuild- oder Visual Studio-Buildtask hinzu, um die .NET Framework Projekte zu erstellen.

• Ihre Builds können beim Wiederherstellen von Paketen zeitweilig fehlschlagen: Entweder tritt NuGet.org Probleme auf, oder es gibt Netzwerkprobleme zwischen dem Azure-Rechenzentrum und NuGet.org. Vielleicht möchten Sie untersuchen, ob die Verwendung von Azure Artifacts mit NuGet.org als Upstream Quelle die Zuverlässigkeit Ihrer Builds verbessert, da sie nicht in unserer Kontrolle liegt.

• Gelegentlich kann ihr Build unterbrochen werden, wenn wir eine neue Version des .NET Core SDK oder Visual Studio bereitstellen. Beispielsweise, wenn eine neuere Version oder ein neueres Feature des NuGet-Tools mit dem SDK ausgeliefert wird. Um dieses Problem zu isolieren, verwenden Sie den Task .NET Core Tool Installer , um die Version des .NET Core SDK anzugeben, die in Ihrem Build verwendet wird.

Häufig gestellte Fragen

F: Wo kann ich mehr über Azure Artifacts und den TFS-Paketverwaltungsdienst erfahren?

A: Paketverwaltung in Azure Artifacts

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

A: .NET Core CLI-Tools

F: Wo kann ich mehr über das Ausführen von Tests in meiner Lösung erfahren?

A: Komponententests in .NET Core-Projekten

F: Wo kann ich mehr über Aufgaben erfahren?

A: Build- und Releasetasks