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:

Hinweis

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

Hinweis

In Microsoft Team Foundation Server (TFS) 2018 und früheren Versionen werden Build- und Release-Pipelines als Definitionen bezeichnet, Ausführungen werden als Builds bezeichnet, Dienstverbindungen werden als Dienstendpunkte bezeichnet, Stages werden als Umgebungen bezeichnet und Aufträge werden als Phasen bezeichnet.

Erstellen Ihrer ersten Pipeline

Sind Sie neu bei Azure-Pipelines? Wenn ja, empfehlen wir Ihnen zunächst den folgenden Abschnitt.

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. Beginnen Sie mit der Installation des neuesten .NET 6.0 SDK.

Erstellen Sie eine neue .NET 6-Webapp.

dotnet new webapp -f net6.0

Führen Sie aus derselben Terminalsitzung die Anwendung lokal mithilfe des dotnet run Befehls aus Ihrem Projektverzeichnis aus.

dotnet run

Code hochladen

Laden Sie Ihren Code in neue Webapp GitHub oder Azure Repos hoch:

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 die Schaltfläche "Neues Projekt " in der oberen rechten Ecke des Dashboards aus.

Erstellen der Pipeline

  1. Melden Sie sich bei Ihrer Azure DevOps-Organisation 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.

Wenn die Registerkarte "Konfigurieren" angezeigt wird, wählen Sie ASP.NET Core aus.

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

    Schaltfläche

  2. Commit einer neuen azure-pipelines.yml-Datei in Ihr Repository. Nachdem Sie mit der Nachricht zufrieden sind, wählen Sie "Speichern" aus, und führen Sie sie erneut aus.

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

    Da Ihr Code eine gute Übereinstimmung für die ASP.NET Core-Vorlage ist, haben wir die Pipeline automatisch für Sie erstellt.

    Sie verfügen jetzt über eine funktionierende YAML-Pipeline (azure-pipelines.yml) in Ihrem Repository, die für Sie bereit ist, anzupassen!

  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ängigeren Möglichkeiten zu erfahren, wie Sie Ihre Pipeline anpassen können.

YAML

  1. Fügen Sie eine azure-pipelines.yml Datei in Ihrem Repository hinzu. Passen Sie den folgenden Codeausschnitt für Ihren Build an.
trigger:
- master

pool: Default

variables:
  buildConfiguration: 'Release'

# do this before all your .NET Core tasks
steps:
- task: DotNetCoreInstaller@2
  inputs:
    version: '2.2.402' # replace this value with the version that you need for your project
- script: dotnet build --configuration $(buildConfiguration)
  displayName: 'dotnet build $(buildConfiguration)'
  1. Erstellen Sie eine Pipeline , und wählen Sie die YAML-Vorlage aus.

  2. Legen Sie den Agentpool und den YAML-Dateipfad für Ihre Pipeline fest.

  3. Speichern Sie die Pipeline und Warteschlange eines Builds. Wenn die Meldung "Build #nnnnnnnn.n " angezeigt wurde, wählen Sie den Nummerlink aus, um Ihre Pipeline in Aktion anzuzeigen.

  4. Wenn Sie bereit sind, Änderungen an Ihrer Pipeline vorzunehmen, bearbeiten Sie sie.

Lesen Sie weiter, um einige der gängigeren Möglichkeiten zu erfahren, wie Sie Ihre Pipeline anpassen können.

Klassisch

  1. Erstellen Sie eine Pipeline , und wählen Sie die Vorlage "Leere Pipeline" aus.

  2. Suchen und hinzufügen Sie im Aufgabenkatalog die .NET Core-Aufgabe . Die folgende Aufgabe wird ausgeführt dotnet build , um den Code im Beispiel-Repository zu erstellen.

  3. Speichern Sie die Pipeline und Warteschlange eines Builds. Wenn die Meldung "Build #nnnnnnnn.n " angezeigt wurde, wählen Sie den Nummerlink aus, um Ihre Pipeline in Aktion anzuzeigen.

    Sie haben jetzt eine arbeitsfähige Pipeline, die für Sie bereit ist, anzupassen!

  4. Wenn Sie bereit sind, Änderungen an Ihrer Pipeline vorzunehmen, bearbeiten Sie sie.

Lesen Sie weiter, um einige der gängigeren Möglichkeiten zu erfahren, wie Sie Ihre Pipeline anpassen können.

Buildumgebung

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

Ubuntu 18.04 wird hier in der YAML-Datei festgelegt.

pool:
  vmImage: 'ubuntu-18.04' # examples of other options: 'macOS-10.15', 'windows-2019'

Weitere Beispiele finden Sie in Microsoft gehosteten Agents für eine vollständige Liste von Bildern und Pool .

Die von Microsoft gehosteten Agents enthalten keine älteren Versionen des .NET Core SDK. Sie enthalten in der Regel keine Vorabversionen. Wenn Sie diese Arten von SDKs auf microsoft gehosteten Agents benötigen, fügen Sie die UseDotNet@2 Aufgabe zu Ihrer YAML-Datei hinzu.

Fügen Sie zum Installieren von 6.0.x SDK zum Erstellen den folgenden Codeausschnitt hinzu:

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

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

steps:
- task: UseDotNet@2
  displayName: 'Install .NET Core SDK'
  inputs:
    version: 5.0.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 selbst gehosteten Agent einrichten. Weitere Informationen finden Sie unter Linux, macOS oder Windows. Sie können auch selbst gehostete Agents verwenden, um zusätzliche Zeit zu sparen, wenn Sie über ein großes Repository verfügen oder inkrementelle Builds ausführen. Ein selbst gehosteter Agent kann Ihnen auch bei der Verwendung der Vorschau oder privaten SDKs helfen, die von Azure DevOps nicht offiziell unterstützt werden oder Sie nur in Ihren lokalen oder lokalen Umgebungen verfügbar sind.

Sie können Ihre .NET Core-Projekte mithilfe des .NET Core SDK und der Laufzeit unter Windows, Linux oder macOS erstellen. Ihre Builds werden auf einem selbst gehosteten Agent ausgeführt. Stellen Sie sicher, dass Sie die erforderliche Version des .NET Core SDK und die Laufzeit auf dem Agent installiert haben.

Wiederherstellen von Abhängigkeiten

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

Sie können NuGet-Pakete aus Azure-Artefakten, 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.

Diese Pipeline verwendet einen Artefaktefeed für dotnet restoredie .NET Core CLI-Aufgabe.

trigger:
- master

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

Sie können NuGet-Pakete aus NuGet.org herunterladen.

dotnet restore intern verwendet eine Version, NuGet.exe die mit dem .NET Core SDK verpackt ist. dotnet restore Kann nur Pakete wiederherstellen, die in den .NET Core-Projektdateien .csproj angegeben sind. 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 NuGet-Aufgabe, um diese Abhängigkeiten wiederherzustellen.

In .NET Core SDK Version 2.0 und neuer werden Pakete automatisch wiederhergestellt, wenn andere Befehle wie z dotnet build. B. ausgeführt werden.

In .NET Core SDK Version 2.0 und neuer werden Pakete automatisch wiederhergestellt, wenn andere Befehle wie z dotnet build. B. ausgeführt werden. Möglicherweise müssen Sie jedoch 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-Artefakte mit upstream-Quellen verwenden und die Pakete zwischenspeichern. Die Anmeldeinformationen der Pipeline werden beim Herstellen einer Verbindung mit Azure-Artefakten automatisch verwendet. Diese Anmeldeinformationen werden in der Regel aus dem Project Collection Build Service-Konto abgeleitet.

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

Wenn Sie 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 eine erhebliche Zeit dauern. Um zu verringern, können Sie entweder Azure-Artefakte oder einen selbst gehosteten Agent mit dem Vorteil der Verwendung des Paketcaches verwenden.

Um Pakete aus einem externen benutzerdefinierten Feed wiederherzustellen, verwenden Sie die folgende .NET Core-Aufgabe :

# 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 in NuGet-Feeds.

  1. Wählen Sie "Aufgaben " in der Pipeline aus. Wählen Sie den Auftrag aus, der Ihre Buildaufgaben ausführt. Wählen Sie + dann aus, um einen neuen Vorgang zu diesem Auftrag hinzuzufügen.

  2. Suchen und hinzufügen Sie im Aufgabenkatalog die .NET Core-Aufgabe .

  3. Wählen Sie die Aufgabe aus, und wählen Sie für Befehl die Wiederherstellung aus.

  4. Geben Sie alle anderen Optionen an, die Sie für diese Aufgabe benötigen. Speichern Sie dann den Build.

Hinweis

Stellen Sie sicher, dass der benutzerdefinierte Feed in Ihrer NuGet.config Datei angegeben ist und die Anmeldeinformationen in der NuGet-Dienstverbindung angegeben werden.

Erstellen Ihres Projekts

Sie erstellen Ihr .NET Core-Projekt entweder durch Ausführen des Befehls in Ihrer Pipeline oder mithilfe der dotnet build .NET Core-Aufgabe.

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

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

Sie können einen beliebigen benutzerdefinierten Dotnet-Befehl in Ihrer Pipeline ausführen. Im folgenden Beispiel wird gezeigt, wie Sie ein globales .NET-Tool installieren und verwenden, dotnetsay:

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

Entwickeln

  1. Wählen Sie "Aufgaben " in der Pipeline aus. Wählen Sie den Auftrag aus, der Ihre Buildaufgaben ausführt. Wählen Sie + dann aus, um diesem Auftrag einen neuen Vorgang hinzuzufügen.

  2. Suchen und hinzufügen Sie im Aufgabenkatalog die .NET Core-Aufgabe .

  3. Wählen Sie die Aufgabe aus, und wählen Sie für Befehlbuild oder veröffentlichen aus.

  4. Geben Sie alle anderen Optionen an, die Sie für diese Aufgabe benötigen, und speichern Sie dann den Build.

Installieren eines Tools

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

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

    • Befehl: benutzerdefinierter Befehl.
      • Pfad zu Projekten: Leer lassen.
    • Benutzerdefinierter Befehl: Tool.
    • Argumente: install -g dotnetsay.
  2. Fügen Sie eine Befehlszeilenaufgabe hinzu, und legen Sie die folgenden Eigenschaften fest:

    • Skript:dotnetsay.

Ausführen der Tests

Wenn Sie Testprojekte in Ihrem Repository haben, verwenden Sie die .NET Core-Aufgabe , um Komponententests auszuführen, indem Sie Testframeworks wie MSTest, xUnit und NUnit.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 zur Problembehandlung fehlgeschlagener Tests und Testzeitzeitanalyse 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)'

Eine Alternative besteht darin, den dotnet test Befehl mit einem bestimmten Logger auszuführen und dann die Aufgabe "Testergebnisse veröffentlichen " zu 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'

Verwenden Sie die .NET Core-Aufgabe mit Command set to test. Pfad zu Projekten sollte auf die Testprojekte in Ihrer Lösung verweisen.

Sammeln von Codeabdeckungen

Wenn Sie auf der Windows-Plattform aufbauen, können Codeabdeckungsmetriken mithilfe des integrierten Datensammlers 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, wird die Abdeckungsdaten automatisch auf dem Server veröffentlicht. Die .Coverage-Datei kann aus der Buildzusammenfassung zum Anzeigen in Visual Studio heruntergeladen 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) --collect "Code coverage"'

Wenn Sie den Befehl ausführen möchten, geben Sie die dotnet test Testergebnisseprotokollier- 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'
  1. Fügen Sie die .NET Core-Aufgabe zu Ihrem Buildauftrag hinzu, und legen Sie die folgenden Eigenschaften fest:

    • Befehl: Testen.
    • Pfad zu Projekten: Sollte auf die Testprojekte in Ihrer Lösung verweisen.
    • Argumente: --configuration $(BuildConfiguration) --collect "Code coverage".
  2. Stellen Sie sicher, dass die Option " Testergebnisse veröffentlichen " ausgewählt bleibt.

Sammeln von Codeabdeckungsmetriken mit Coverlet

Wenn Sie auf Linux oder macOS erstellen, können Sie Coverlet oder ein ähnliches Tool verwenden, um Codeabdeckungsmetriken zu sammeln.

Sie können Codeabdeckungsergebnisse auf dem Server mit der Aufgabe "Codeabdeckungsergebnisse veröffentlichen" veröffentlichen. Das Abdeckungstool muss so konfiguriert werden, dass Ergebnisse im Cobertura- oder JaCoCo-Abdeckungsformat generiert werden.

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

  • Fügen Sie einen Verweis auf das coverlet.msbuild NuGet-Paket in Ihrem Testprojekt für .NET-Projekte unterhalb von .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:
- task: UseDotNet@2
  inputs:
    version: '5.0.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'

Packen und Bereitstellen des 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 verpacken, 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 die CLI aus, oder fügen Sie dotnet publish --output $(Build.ArtifactStagingDirectory) die DotNetCoreCLI@2 Aufgabe mit dem Veröffentlichungsbefehl hinzu.
  • Veröffentlichen Sie das Artefakte mithilfe der Aufgabe "Veröffentlichen von Artefakten".

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 Repo. Weitere Hilfe und Informationen finden Sie in der Open Source Aufgabe auf GitHub.

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

Veröffentlichen in einem NuGet-Feed

Fügen Sie zum Erstellen und Veröffentlichen eines NuGet-Pakets 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 in NuGet-Feeds.

Bereitstellen einer Web-App

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

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.

Veröffentlichen von Artefakten in Azure-Pipelines

Verwenden Sie die Aufgabe " Artefakte veröffentlichen", um die Ausgabe Ihres Builds in Azure-Pipelines zu veröffentlichen.

Veröffentlichen in einem NuGet-Feed

Wenn Sie Ihren Code in einem NuGet-Feed veröffentlichen möchten, führen Sie die folgenden Schritte aus:

  1. Verwenden Sie eine .NET Core-Aufgabe mit Command set to pack.

  2. Veröffentlichen Sie Ihr Paket in einem NuGet-Feed.

Bereitstellen einer Web-App

  1. Verwenden Sie eine .NET Core-Aufgabe mit Befehl , die zum Veröffentlichen festgelegt ist.

  2. Stellen Sie sicher, dass Sie die Option zum Erstellen eines .zip Dateiarchivs ausgewählt haben.

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

Erstellen eines Images und Push in 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 auf Azure Pipelines haben, erkunden Sie die folgenden potenziellen Ursachen und Korrekturmaßnahmen:

  • Wir installieren keine Vorabversionen des .NET Core SDK auf von Microsoft gehosteten Agents. Nachdem eine neue Version des .NET Core SDK veröffentlicht wurde, kann es einige Wochen dauern, bis alle Azure Pipelines-Rechenzentren eingeführt werden. Sie müssen nicht warten, bis dieses Rollout abgeschlossen ist. Sie können das .NET Core Tool Installer 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 -Laufzeit auf Ihrem Entwicklungscomputer, und stellen Sie sicher, dass sie dem Agent entsprechen. Sie können ein Befehlszeilenskript dotnet --version in Ihre Pipeline einschließen, 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 neuere Version des .NET Core SDK.

  • Möglicherweise verwenden Sie einige Logik in der Visual Studio-IDE, die nicht in Ihrer Pipeline codiert ist. Azure Pipelines führt die einzelnen Befehle aus, die Sie in den Aufgaben nacheinander in einem neuen Prozess angeben. Untersuchen Sie die Protokolle aus dem Pipelinesbuild, um die genauen Befehle anzuzeigen, die als Teil 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 Lösung verfügen, die einige .NET Core-Projekte und einige .NET Framework Projekte enthält, sollten Sie auch die NuGet-Aufgabe verwenden, um pakete wiederherzustellen, die in packages.config Dateien angegeben sind. Fügen Sie die MSBuild- oder Visual Studio Build-Aufgabe hinzu, um die .NET Framework Projekte zu erstellen.

  • Ihre Builds können beim Wiederherstellen von Paketen möglicherweise fehlschlagen: entweder NuGet.org Probleme haben, oder es gibt Netzwerkprobleme zwischen dem Azure-Rechenzentrum und NuGet.org. Möglicherweise möchten Sie untersuchen, ob Die Verwendung von Azure-Artefakten mit NuGet.org als upstream-Quelle die Zuverlässigkeit Ihrer Builds verbessert, da sie nicht in unserem Steuerelement enthalten ist.

  • Wenn wir gelegentlich eine neue Version des .NET Core SDK oder Visual Studio bereitstellen, kann ihr Build unterbrechen. Wenn beispielsweise eine neuere Version oder ein Feature des NuGet-Tools mit dem SDK ausgeliefert wird. Um dieses Problem zu isolieren, verwenden Sie die .NET Core Tool Installer-Aufgabe , um die Version des .NET Core SDK anzugeben, das in Ihrem Build verwendet wird.

Häufig gestellte Fragen

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

A: Paketverwaltung in Azure-Artefakten

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

A: .NET Core CLI-Tools

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

A: Komponententests in .NET Core-Projekten

F: Wo kann ich mehr über Aufgaben erfahren?

A: Erstellen und Freigeben von Aufgaben