Entwickeln, Testen und Bereitstellen von .NET Core-Apps

Azure Pipelines | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 | TFS 2017

Verwenden Sie eine Pipeline, um Ihre .NET Core-Projekte automatisch zu erstellen und zu testen. In diesem Artikel werden folgende Themen erläutert:

Hinweis

Hilfe zu .NET Framework Projekten finden Sie unter Erstellen 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.

Hinweis

Dieser Leitfaden gilt für TFS-Version 2017.3 und höher.

Erstellen Ihrer ersten Pipeline

Sind Sie noch nicht mit Azure Pipelines? Wenn ja, sollten Sie diesen Abschnitt ausprobieren, bevor Sie mit anderen Abschnitten fortfahren.

Abrufen des Codes

Verzweigen Sie dieses Repository in GitHub:

Importieren Sie dieses Repository in Ihr Git-Repository in Azure DevOps Server 2019:

Importieren Sie dieses Repository in Ihr Git-Repository in TFS:

https://github.com/MicrosoftDocs/pipelines-dotnet-core

Anmelden bei Azure Pipelines

Melden Sie sich bei Azure Pipelinesan. Nachdem Sie sich angemeldet haben, wechselt Ihr Browser zum https://dev.azure.com/my-organization-name Azure devops-Dashboard und zeigt es an.

Erstellen Sie in der ausgewählten Organisation ein Projekt. Wenn Sie über keine Projekte in Ihrer Organisation verfügen, sehen Sie den Bildschirm Erstellen eines Projekts für den Einstieg. Wählen Sie andernfalls in der oberen rechten Ecke des Dashboards die Schaltfläche Projekt erstellen aus.

Erstellen der Pipeline

  1. Melden Sie sich bei Ihrer Azure DevOps-Organisation an, und navigieren Sie zu Ihrem Projekt.

  2. Wechseln Sie zu Pipelines, und wählen Sie dann neue Pipeline aus.

  3. Führen Sie die Schritte des Assistenten aus. 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 Repository angezeigt wird, wählen Sie Ihr Repository aus.

  6. Sie werden möglicherweise zu GitHub weitergeleitet, um die Azure Pipelines-App zu installieren. Wenn dies der Fall ist, wählen Sie & Installation genehmigen.

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

  1. Wenn Ihre neue Pipeline angezeigt wird, sehen Sie sich die YAML an, um zu sehen, was sie tut. Wenn Sie bereit sind, wählen Sie Speichern aus, und führen Sie aus.

    Schaltfläche "Speichern und ausführen" in einer neuen YAML-Pipeline

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

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

    Sie haben soeben eine Pipeline erstellt und ausgeführt, die wir automatisch für Sie erstellt haben, da Ihr Code für die ASP.NET Core-Vorlage gut zu passen schien.

    Sie verfügen nun über eine funktionierende YAML-Pipeline ( ) in Ihrem Repository, die Sie anpassen azure-pipelines.yml 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.

  4. In den folgenden Abschnitten finden Sie einige der gängigeren Möglichkeiten zum Anpassen Ihrer Pipeline.

YAML

  1. Fügen Sie azure-pipelines.yml ihrem Repository eine Datei hinzu. Passen Sie diesen 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 (wenn Sie nicht wissen, wie Sie ihre erste Pipeline erstellen),und wählen Sie für die Vorlage YAML aus.

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

  3. Speichern Sie die Pipeline, und stellen Sie einen Build in die Warteschlange. Wenn die Meldung Build #nnnnnnnn.n has queued (Build #nnnnnnnn.n wurde in die Warteschlange gestellt) angezeigt wird, wählen Sie den Nummernlink aus, um Ihre Pipeline in Aktion zu sehen.

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

  5. In den folgenden Abschnitten finden Sie einige der gängigeren Möglichkeiten zum Anpassen Ihrer Pipeline.

Klassisch

  1. Erstellen Sie eine Pipeline (wenn Sie nicht wissen, wie sie funktioniert, finden Sie weitere Informationen unter Erstellen Ihrer ersten Pipeline). Wählen Sie leere Pipeline für die Vorlage aus.

  2. Suchen Sie im Aufgabenkatalog nach der .NET Core-Aufgabe, und fügen Sie sie hinzu. Diese Aufgabe wird dotnet build ausgeführt, um den Code im Beispielrepository zu erstellen.

  3. Speichern Sie die Pipeline, und stellen Sie einen Build in die Warteschlange. Wenn die Meldung Build #nnnnnnnn.n has queued (Build #nnnnnnnn.n wurde in die Warteschlange gestellt) angezeigt wird, wählen Sie den Nummernlink aus, um Ihre Pipeline in Aktion zu sehen.

    Sie verfügen nun über eine funktionierende Pipeline, die Sie anpassen können!

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

  5. In den folgenden Abschnitten finden Sie einige der gängigeren Möglichkeiten zum Anpassen Ihrer Pipeline.

Buildumgebung

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

Ubuntu 18.04 ist hier in der YAML-Datei festgelegt.

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

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

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

Um die Vorschauversion des SDK 5.0.x zum Erstellen und 3.0.x zum Ausführen von Tests für .NET Core 3.0.x zu installieren, fügen Sie den folgenden Codeausschnitt hinzu:

steps:
- task: UseDotNet@2
  inputs:
    version: '5.0.x'
    includePreviewVersions: true # Required for preview versions

- task: UseDotNet@2
  inputs:
    version: '3.0.x'
    packageType: runtime

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

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

Tipp

Alternativ können Sie einen selbstgehosteten Agent einrichten und die Kosten für die Ausführung des Toolinstallationsprogramms sparen. Weitere Informationen finden Sie unter Linux, MacOSoder 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 Vorschauversion oder der privaten SDKs helfen, die von Azure DevOps nicht offiziell unterstützt werden oder nur in Ihren Unternehmensumgebungen oder lokalen Umgebungen verfügbar sind.

Sie können Ihre .NET Core-Projekte mithilfe des .NET Core SDK und der Runtime unter Windows, Linux oder macOS erstellen. Ihre Builds werden auf einem selbstgehosteten Agentausgeführt. Stellen Sie sicher, dass auf dem Agent die erforderliche .NET Core SDK und Runtime installiert ist.

Wiederherstellen von Abhängigkeiten

NuGet ist eine beliebte Möglichkeit, 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 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 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.

Diese Pipeline verwendet einen Artefaktfeed dotnet restore für im .NET Core-CLI Task.

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 von NuGet.org.

dotnet restore verwendet intern eine Version von NuGet.exe , die mit dem Paket .NET Core SDK. dotnet restore kann nur pakete wiederherstellen, die in den .NET Core-Projektdateien angegeben .csproj sind. Wenn Sie auch ein Microsoft .NET Framework-Projekt in Ihrer Projektmappe haben oder verwenden, um Ihre Abhängigkeiten anzugeben, müssen Sie auch die package.json NuGet-Aufgabe verwenden, um diese Abhängigkeiten wiederherzustellen.

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

In .NET Core SDK Version 2.0 und neuer werden Pakete automatisch wiederhergestellt, wenn andere Befehle wie ausgeführt dotnet build werden. Möglicherweise müssen Sie jedoch weiterhin den .NET Core-Task verwenden, um Pakete wiederherzustellen, wenn Sie einen authentifizierten Feed verwenden.

Wenn Ihre Builds beim Wiederherstellen von Paketen aus NuGet.org aufgrund von Verbindungsproblemen gelegentlich fehlschlagen, können Sie Azure Artifacts mit Upstreamquellen verwenden und die Pakete zwischenspeichern. Die Anmeldeinformationen der Pipeline werden automatisch verwendet, wenn sie eine Verbindung mit Azure Artifacts. Diese Anmeldeinformationen werden in der Regel vom Projektsammlungs-Builddienstkonto abgeleitet.

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

Wenn Sie von Microsoft gehostete Agents verwenden, erhalten Sie bei jeder Ausführung eines Builds einen neuen Computer. Dies bedeutet, dass die Pakete jedes Mal wiederhergestellt werden. Diese Wiederherstellung kann viel Zeit in Anspruch nehmen. Um dieses Problem zu beheben, können Sie entweder Azure Artifacts oder einen selbstgehosteten Agent verwenden. In diesem Fall profitieren Sie von der Verwendung des Paketcaches.

Verwenden Sie den .NET Core-Task, 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.

  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 eine neue Aufgabe hinzuzufügen.

  2. Suchen Sie im Aufgabenkatalog nach der .NET Core-Aufgabe, und fügen Sie sie hinzu.

  3. Wählen Sie die Aufgabe aus, und wählen Sie unter Befehl die Option wiederherstellen 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 Datei angegeben ist NuGet.config und dass die Anmeldeinformationen in der NuGet-Dienstverbindung angegeben sind.

Erstellen Ihres Projekts

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

Um Ihr Projekt mithilfe der .NET Core-Aufgabe zu erstellen, fügen Sie der Datei den folgenden Codeausschnitt azure-pipelines.yml 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. Das folgende Beispiel zeigt, wie Sie ein globales .NET-Tool dotnetsayinstallieren und verwenden:

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, mit dem Ihre Buildaufgaben ausgeführt werden. Wählen Sie dann + aus, um diesem Auftrag eine neue Aufgabe hinzuzufügen.

  2. Suchen Sie im Aufgabenkatalog nach der .NET Core-Aufgabe, und fügen Sie sie hinzu.

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

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

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 den .NET Core-Task hinzu, und legen Sie die folgenden Eigenschaften fest:

    • Befehl: benutzerdefiniert.
      • Pfad zu Projekten: Lassen Sie leer.
    • Benutzerdefinierter Befehl: Tool.
    • Argumente: install -g dotnetsay .
  2. Fügen Sie einen Befehlszeilen-Task hinzu, und legen Sie die folgenden Eigenschaften fest:

    • Skript: dotnetsay .

Ausführen der Tests

Wenn Sie über Testprojekte in Ihrem Repository verfügen, verwenden Sie den .NET Core-Task, um Komponententests mithilfe von Testframeworks wie MSTest, xUnit und NUnit auszuführen. Für diese Funktionalität muss das Testprojekt auf Microsoft .NET.Test.SDK Version 15.8.0 oder höher verweisen. Testergebnisse werden automatisch im Dienst veröffentlicht. Diese Ergebnisse werden Ihnen dann in der Buildzusammenfassung zur Verfügung gestellt und können für die Problembehandlung fehlgeschlagener Tests und die Analyse der Testzeit verwendet werden.

Fügen Sie ihrer Datei den folgenden azure-pipelines.yml 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 den Task Publish Testergebnisse 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 den .NET Core-Task mit dem Befehlssatz , um zu testen. Der Pfad zu Projekten sollte auf die Testprojekte in Ihrer Projektmappe verweisen.

Erfassen von Code Coverage

Wenn Sie auf der Windows-Plattform aufbauen, können Code Coverage-Metriken mithilfe des integrierten Abdeckungsdatensammlers erfasst werden. Für diese Funktionalität muss das Testprojekt auf Microsoft .NET.Test.SDK Version 15.8.0 oder höher verweisen. Wenn Sie den .NET Core-Task zum Ausführen von Tests verwenden, werden 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 Datei den folgenden Codeausschnitt azure-pipelines.yml 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 dotnet test möchten, geben Sie die Protokollierungs- und Abdeckungsoptionen für Testergebnisse 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 ihrem Buildauftrag den .NET Core-Task hinzu, und legen Sie die folgenden Eigenschaften fest:

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

Sammeln von Code Coverage-Metriken mit Coverlet

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

Code Coverage-Ergebnisse können mithilfe des Tasks Code Coverage-Ergebnisse veröffentlichen auf dem Server veröffentlicht werden. Um diese Funktion verwenden zu können, muss das Abdeckungstool so konfiguriert werden, dass Ergebnisse im Cobertura- oder JaCoCo-Abdeckungsformat generiert werden.

So führen Sie Tests aus und veröffentlichen Code Coverage mit Coverlet:

  • Fügen Sie in Ihren Testprojekten für .NET-Projekte unter .NET 5 einen Verweis auf coverlet.msbuild das NuGet-Paket hinzu. Fügen Sie für .NET 5 einen Verweis auf das coverlet.collector NuGet-Paket hinzu.
  • Fügen Sie der Datei den codeausschnitt azure-pipelines.yml 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" /p:CoverletOutputFormat=cobertura /p:CoverletOutput=$(Build.SourcesDirectory)/TestResults/Coverage/'
    publishTestResults: true
    projects: 'MyTestLibrary' # update with your test project directory
  
- task: PublishCodeCoverageResults@1
  displayName: 'Publish code coverage report'
  inputs:
    codeCoverageTool: 'Cobertura'
    summaryFileLocation: '$(Build.SourcesDirectory)/**/coverage.cobertura.xml'

Packen und Liefern Ihres Codes

Nachdem Sie Ihre App erstellt und getestet haben, können Sie die Buildausgabe in Azure Pipelines oder TFS hochladen, ein NuGet-Paket erstellen und veröffentlichen oder die Buildausgabe in eine ZIP-Datei packen, um in einer Webanwendung bereitgestellt zu werden.

Veröffentlichen von Artefakten in Azure Pipelines

Um die Ausgabe Ihres .NET-Build zu veröffentlichen,

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

Fügen Sie ihrer Datei den folgenden azure-pipelines.yml 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

Der dotNetCoreCLI@2 Task verfügt über eine publishWebProjects Eingabe, die standardmäßig auf TRUE festgelegt ist. Dadurch werden standardmäßig alle Webprojekte in Ihrem Repository veröffentlicht. Weitere Hilfe und Informationen finden Sie in der Open Source-Aufgabe auf GitHub.

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

Veröffentlichen in einem NuGet-Feed

Fügen Sie den folgenden Codeausschnitt hinzu, um ein NuGet-Paket zu erstellen und zu veröffentlichen:

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 Versions- 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 Bereitstellung von Azure-Web-Apps.

Veröffentlichen von Artefakten in Azure Pipelines

Verwenden Sie den Task Artefakte veröffentlichen, um die Ausgabe Ihres Builds in Azure Pipelines oder TFS 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, bei der command auf pack festgelegt ist.

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

Bereitstellen einer Web-App

  1. Verwenden Sie eine .NET Core-Aufgabe mit befehlssatz zum Veröffentlichen.

  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 Bereitstellung von Azure-Web-Apps.

Erstellen eines Images und Pushen an die Containerregistrierung

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

Problembehandlung

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

  • Auf von Microsoft gehosteten Agents werden keine Vorabversionen der .NET Core SDK installiert. Nachdem eine neue Version der .NET Core SDK veröffentlicht wurde, kann es einige Wochen dauern, bis wir sie für alle Rechenzentren, in denen Azure Pipelines ausgeführt werden, rollouten. Sie müssen nicht warten, bis wir diesen Rollout abgeschlossen haben. Sie können den Installer für das .NET Core-Tool wie in diesem Leitfaden erläutert verwenden, um die gewünschte Version der .NET Core SDK auf von Microsoft gehosteten Agents zu installieren.
  • Überprüfen Sie, ob die Versionen des .NET Core SDK und der Runtime auf Ihrem Entwicklungscomputer mit denen auf dem Agent übereinstimmen. Sie können ein Befehlszeilenskript dotnet --version in Ihre Pipeline einfügen, um die Version des .NET Core SDK ausdrucken zu können. Verwenden Sie entweder den Installer für das .NET Core-Tool, wie in diesem Leitfaden erläutert, um die gleiche Version auf dem Agent bereitzustellen, oder aktualisieren Sie Ihre Projekte und den Entwicklungscomputer auf die neuere Version des .NET Core SDK.

  • Möglicherweise verwenden Sie logik in der Visual Studio IDE, die nicht in Ihrer Pipeline codiert ist. Azure Pipelines oder TFS führt jeden der Befehle aus, die Sie in den Tasks nacheinander in einem neuen Prozess angeben. Sehen Sie sich die Protokolle aus dem Azure Pipelines oder TFS-Build an, um die genauen Befehle anzuzeigen, die als Teil des Build 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 Dateien angegebene Pakete packages.config wiederherzustellen. Ebenso sollten Sie MSBuild hinzufügen oder Buildaufgaben Visual Studio erstellen, um die .NET Framework erstellen.

  • Wenn Ihre Builds beim Wiederherstellen von Paketen zeitweilig fehlschlagen, liegt entweder NuGet.org Probleme vor, oder es liegen Netzwerkprobleme zwischen dem Azure-Rechenzentrum und dem NuGet.org. Diese befinden sich nicht unter unserer Kontrolle, und Sie müssen möglicherweise untersuchen, ob die Verwendung von Azure Artifacts mit NuGet.org als Upstreamquelle die Zuverlässigkeit Ihrer Builds verbessert.

  • Wenn wir gelegentlich ein Update für die gehosteten Images mit einer neuen Version des .NET Core SDK oder Visual Studio, kann es zu einem Buildabbruch kommt. Dies kann beispielsweise der Fall sein, wenn eine neuere Version oder funktion des NuGet-Tools mit dem SDK ausgeliefert wird. Um diese Probleme zu isolieren, verwenden Sie den .NET Core-Toolinstallations-Task, um die Version der .NET Core SDK, die in Ihrem Build verwendet wird, anzugeben.

Häufig gestellte Fragen

Wo kann ich mehr über Azure Artifacts und den TFS-Paketverwaltung erfahren?

Paketverwaltung in Azure Artifacts und TFS

Wo finde ich weitere Informationen zu .NET Core-Befehlen?

.NET Core CLI-Tools

Wo finde ich weitere Informationen zum Ausführen von Tests in meiner Lösung?

Komponententests in .NET Core-Projekten

Wo finde ich weitere Informationen zu Aufgaben?

Entwickeln und Veröffentlichen von Tasks