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:

• Einrichten Ihrer Buildumgebung mit von Microsoft gehosteten oder selbstgehosteten Agents
• Wiederherstellen von Abhängigkeiten, Erstellen Ihres Projekts und Testen mit der .NET Core CLI-Aufgabe oder einem Skript
• Verwenden der Aufgabe zum Veröffentlichen von Code Coverage zum Veröffentlichen von Code Coverage-Ergebnissen
• Packen und Bereitstellen von Code mit der .NET Core-CLI-Aufgabe und der Aufgabe zum Veröffentlichen von Buildartefakten
• Veröffentlichen in einem NuGet-Feed
• Bereitstellen Ihrer Web-App in Azure

Hinweis

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

Erstellen Ihrer ersten Pipeline

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

Erstellen eines .NET-Projekts.

Wenn Sie 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 eines neuen Git-Repositorys in Azure Repos
• Erstellen eines neuen GitHub-Repositorys

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

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

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

   

2. Committen Sie eine neue Datei azure-pipelines.yml im Repository. Sobald Sie mit der Nachricht zufrieden sind, klicken Sie erneut auf Speichern und ausführen.

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

   Da Ihr Code für die ASP.NET Core-Vorlage geeignet schien, wurde Ihre Pipeline automatisch erstellt.

   Sie verfügen nun über 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.

In den folgenden Abschnitten erfahren Sie mehr über die gängigen Möglichkeiten zum Anpassen Ihrer Pipeline.

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 umfassen 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.

In den von Microsoft gehosteten Agents sind einige der älteren Versionen des .NET Core SDK nicht enthalten. 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 Aufgabe UseDotNet@2 hinzu.

Um das 6.0.x SDK für die Erstellung zu installieren, fügen Sie den folgenden Codeschnipsel 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 performMultiLevelLookup im folgenden Codeschnipsel auf true fest:

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. Informationen finden Sie unter Linux, macOS oder Windows. Sie können selbstgehostete Agents auch verwenden, um zusätzlich Zeit zu sparen, wenn Sie über ein großes Repository verfügen oder inkrementelle Builds ausführen. Ein selbstgehosteter 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 zum Herstellen einer Abhängigkeit von Code, den Sie nicht erstellen. Sie können NuGet-Pakete und projektspezifische Tools herunterladen, die in der Projektdatei angegeben sind, indem Sie den Befehl dotnet restore entweder über die .NET Core-Aufgabe oder direkt in einem Skript in Ihrer Pipeline ausführen.

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

Diese Pipeline verwendet einen 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 verwendet intern eine Version von NuGet.exe, die mit dem .NET Core SDK gepackt ist. dotnet restore kann nur Pakete wiederherstellen, die in den .csproj-Projektdateien von .NET Core angegeben sind. Wenn Sie auch ein Microsoft .NET Framework-Projekt in Ihrer Projektmappe haben oder package.json zum Angeben Ihrer Abhängigkeiten nutzen, verwenden Sie die NuGet-Aufgabe, um diese Abhängigkeiten wiederherzustellen.

Im .NET Core SDK, Version 2.0 und höher, werden Pakete automatisch wiederhergestellt, wenn andere Befehle wie z. B. dotnet buildausgeführt werden. Möglicherweise müssen Sie jedoch weiterhin die .NET Core-Aufgabe zum Wiederherstellen von Paketen verwenden, wenn Sie einen authentifizierten Feed nutzen.

Ihre Builds können gelegentlich aufgrund von Verbindungsfehlern fehlschlagen, wenn Sie Pakete aus NuGet.org wiederherstellen. Sie können Azure Artifacts mit Upstreamquellen verwenden und die Pakete zwischenspeichern. Die Anmeldeinformationen der Pipeline werden beim Herstellen einer Verbindung mit Azure Artifacts automatisch verwendet. Diese Anmeldeinformationen werden in der Regel vom Projektsammlungs-Builddienst-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 die zugehörigen Anmeldeinformationen, indem Sie eine NuGet-Dienstverbindung auf der Registerkarte Dienste unter Projekteinstellungen erstellen.

Wenn Sie von Microsoft gehostete Agents verwenden, erhalten Sie bei jeder Ausführung eines Builds einen neuen Computer, was bedeutet, dass die Pakete jedes Mal wiederhergestellt werden. Die Wiederherstellung kann sehr lange dauern. Zur Entschärfung können Sie entweder Azure Artifacts oder einen selbstgehosteten Agent verwenden, um von der Verwendung des Paketcache zu profitieren.

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 Befehl dotnet build in Ihrer Pipeline ausführen oder die .NET Core-Aufgabe verwenden.

Um Ihr Projekt mit der .NET Core-Aufgabe zu erstellen, fügen Sie der azure-pipelines.yml-Datei den folgenden Codeschnipsel 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, 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 Ihr Repository Testprojekte umfasst, 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 Ihrer Datei azure-pipelines.yml den folgenden Codeschnipsel 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 Befehl dotnet test 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 Builds auf der Windows-Plattform erstellen, können Code Coverage-Metriken mithilfe des integrierten Abdeckungs-Collectors 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 und in Visual Studio angezeigt werden.

Fügen Sie Ihrer Datei azure-pipelines.yml den folgenden Codeschnipsel hinzu:

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

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

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

Sammeln von Code Coverage-Metriken mit Coverlet

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

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

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

• Fügen Sie einen Verweis auf das NuGet-Paket coverlet.msbuild in Ihren Testprojekten für .NET-Projekte unter .NET 5 hinzu. Fügen Sie für .NET 5 einen Verweis auf das NuGet-Paket coverlet.collector hinzu.
• Fügen Sie Ihrer Datei azure-pipelines.yml den folgenden Codeschnipsel 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'

Verpacken und Übermitteln von Code

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) in der CLI aus, oder fügen Sie die Aufgabe „DotNetCoreCLI@2“ mit dem Veröffentlichungsbefehl hinzu.
• Veröffentlichen Sie das Artefakt mithilfe der Aufgabe „Artefakt veröffentlichen“.

Fügen Sie Ihrer Datei azure-pipelines.yml den folgenden Codeschnipsel 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 Aufgabe dotNetCoreCLI@2 verfügt über eine Eingabe publishWebProjects, die standardmäßig auf true festgelegt ist. Diese Aufgabe veröffentlicht standardmäßig alle Webprojekte in Ihrem Repository. 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 CopyFiles.

Veröffentlichen in einem NuGet-Feed

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

Bereitstellen einer Web-App

Fügen Sie den folgenden Codeschnipsel 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-App-Bereitstellung.

Erstellen eines Images und Pushen in eine Containerregistrierung

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

Problembehandlung

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

• 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 ist. Sie müssen nicht warten, bis das Rollout abgeschlossen ist. Sie können den .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 -Runtime auf Ihrem Entwicklungscomputer, und stellen Sie sicher, dass sie mit dem Agent übereinstimmen. Sie können ein Befehlszeilenskript dotnet --version in Ihre Pipeline einschließen, um die Version des .NET Core SDK zu drucken. Verwenden Sie entweder den .NET Core Tool-Installer, um dieselbe Version auf dem Agent bereitzustellen, oder aktualisieren Sie Ihre Projekte und Ihren Entwicklungscomputer auf die neuere Version des .NET Core SDK.

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

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

• Ihre Builds können beim Wiederherstellen von Paketen zeitweilig fehlschlagen: Entweder treten bei NuGet.org Probleme auf, oder es gibt Netzwerkprobleme zwischen dem Azure-Rechenzentrum und NuGet.org. Sie sollten untersuchen, ob die Verwendung von Azure Artifacts mit NuGet.org als Upstreamquelle die Zuverlässigkeit Ihrer Builds verbessert, da dies nicht in unseren Kontrollbereich fällt.

• Gelegentlich kann die Funktion Ihres Builds beeinträchtigt werden, wenn wir eine neue Version des .NET Core SDK oder von Visual Studio bereitstellen. Dies ist beispielsweise der Fall, wenn eine neuere Version oder ein neueres Feature des NuGet-Tools mit dem SDK ausgeliefert wird. Um dieses Problem einzugrenzen, verwenden Sie die Aufgabe .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 erfahre ich mehr über .NET Core-Befehle?

A: .NET Core-CLI-Tools

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

A: Komponententests in .NET Core-Projekten

F: Wo erfahre ich mehr über Aufgaben?

A: Entwickeln und Veröffentlichen von Aufgaben