{"meta":{"title":"Erstellen und Testen eines .NET-Projekts","intro":"Hier erfährst, du, wie du einen CI-Workflow (Continuous Integration) erstellst, um dein .NET-Projekt zu erstellen und zu testen.","product":"GitHub Actions","breadcrumbs":[{"href":"/de/actions","title":"GitHub Actions"},{"href":"/de/actions/tutorials","title":"Anleitungen"},{"href":"/de/actions/tutorials/build-and-test-code","title":"Erstellen und Testen von Code"},{"href":"/de/actions/tutorials/build-and-test-code/net","title":".NET"}],"documentType":"article"},"body":"# Erstellen und Testen eines .NET-Projekts\n\nHier erfährst, du, wie du einen CI-Workflow (Continuous Integration) erstellst, um dein .NET-Projekt zu erstellen und zu testen.\n\n## Einführung\n\nIn dieser Anleitung erfährst du, wie du ein .NET-Paket erstellst, testest und veröffentlichst.\n\nGitHub-gehostete Runner verfügen über einen Toolcache mit vorinstallierter Software, der auch das .NET Core SDK enthält. Eine vollständige Liste der aktuellen Software und der vorinstallierten Versionen des .NET Core SDK finden Sie unter [Auf GitHub-gehosteten Runnern installierte Software](/de/actions/concepts/runners/github-hosted-runners).\n\n## Voraussetzungen\n\nSie sollten bereits mit der YAML-Syntax und damit vertraut sein, wie sie mit GitHub Actions verwendet wird. Weitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax).\n\nDu solltest über grundlegende Kenntnisse in Bezug auf das .NET Core SDK verfügen. Weitere Informationen findest du unter [Erste Schritte mit .NET](https://dotnet.microsoft.com/learn).\n\n## Verwenden einer .NET-Workflowvorlage\n\nFügen Sie für einen schnellen Einstieg dem Verzeichnis `.github/workflows` Ihres Repositorys eine Workflowvorlage hinzu.\n\nGitHubstellt eine Workflowvorlage für .NET bereit, die für die meisten .NET Projekte funktionieren sollte. In den nachfolgenden Abschnitten dieser Anleitung finden Sie Beispiele dafür, wie diese Workflowvorlage angepasst werden kann.\n\n1. Navigieren Sie auf GitHub zur Hauptseite des Repositorys.\n\n2. Klicke unter dem Repositorynamen auf ** Actions**.\n\n \n\n3. Wenn du bereits über einen Workflow im Repository verfügst, klicke auf **Neuer Workflow**.\n\n4. Auf der Seite „Workflow auswählen“ wird eine Auswahl empfohlener Workflowvorlagen angezeigt. Suchen Sie nach \"dotnet\".\n\n5. Klicken Sie im Workflow „.NET“ auf **Konfigurieren**.\n\n6. Bearbeiten Sie den Workflow nach Bedarf. Ändern Sie beispielsweise die .NET-Version.\n\n7. Klicke auf **Änderungen übernehmen**.\n\n Die `dotnet.yml` Workflowdatei wird dem `.github/workflows` Verzeichnis Ihres Repositorys hinzugefügt.\n\n## Angeben einer .NET-Version\n\nUm eine vorinstallierte Version des .NET Core SDK auf einem von GitHub gehosteten Runner zu verwenden, verwenden Sie die `setup-dotnet`-Action. Mit dieser Aktion wird im Toolcache der jeweiligen Runner nach einer bestimmten Version von .NET gesucht, und die erforderlichen Binärdateien werden zu `PATH` hinzugefügt. Diese Änderungen bleiben für den Rest des Auftrags beibehalten.\n\nDie `setup-dotnet` Aktion ist die empfohlene Methode für die Verwendung von .NET mit GitHub Actions, da sie ein konsistentes Verhalten in verschiedenen Runnern und in verschiedenen Versionen von .NET sicherstellt. Wenn du einen selbst gehosteten Runner verwendest, musst du .NET installieren und zu `PATH` hinzufügen. Weitere Informationen findest du unter der Aktion [`setup-dotnet`](https://github.com/marketplace/actions/setup-net-core-sdk).\n\n### Verwenden mehrerer .NET-Versionen\n\n```yaml\nname: dotnet package\n\non: [push]\n\njobs:\n build:\n\n runs-on: ubuntu-latest\n strategy:\n matrix:\n dotnet-version: [ '3.1.x', '6.0.x' ]\n\n steps:\n - uses: actions/checkout@v6\n - name: Setup dotnet ${{ matrix.dotnet-version }}\n uses: actions/setup-dotnet@v4\n with:\n dotnet-version: ${{ matrix.dotnet-version }}\n # You can test your matrix by printing the current dotnet version\n - name: Display dotnet version\n run: dotnet --version\n```\n\n### Verwenden einer bestimmten .NET-Version\n\nDu kannst einen Auftrag so konfigurieren, dass eine bestimmte Version von .NET verwendet wird, z. B. `6.0.22`. Alternativ kannst du auch Syntax für semantische Versionierung verwenden, um die neuste Nebenversion abzurufen. In diesem Beispiel wird die neueste Nebenversion von .NET 6 verwendet.\n\n```yaml\n - name: Setup .NET 6.x\n uses: actions/setup-dotnet@v4\n with:\n # Semantic version range syntax or exact version of a dotnet version\n dotnet-version: '6.x'\n```\n\n## Installieren von Abhängigkeiten\n\nGitHub-gehostete Runner haben den NuGet-Paket-Manager installiert. Du kannst die dotnet-CLI verwenden, um Abhängigkeiten aus der NuGet-Paketregistrierung zu installieren, bevor du deinen Code erstellst und testest. Mit dem folgenden YAML-Code wird beispielsweise das `Newtonsoft`-Paket installiert.\n\n```yaml\nsteps:\n- uses: actions/checkout@v6\n- name: Setup dotnet\n uses: actions/setup-dotnet@v4\n with:\n dotnet-version: '6.0.x'\n- name: Install dependencies\n run: dotnet add package Newtonsoft.Json --version 12.0.1\n```\n\n### Abhängigkeiten „cachen“ (zwischenspeichern)\n\nSie können NuGet-Abhängigkeiten für zukünftige Workflows anhand der optionalen Eingabe `cache` zwischenspeichern. So nimmt zum Beispiel das folgende YAML eine Zwischenspeicherung des NuGet-Ordners `global-packages` vor und installiert dann das `Newtonsoft`-Paket. Mit einer zweiten optionalen Eingabe, `cache-dependency-path`, kann der Pfad zu einer Abhängigkeitsdatei angegeben werden: `packages.lock.json`.\n\nWeitere Informationen finden Sie unter [Referenz zum Zwischenspeichern von Abhängigkeiten](/de/actions/reference/workflows-and-actions/dependency-caching).\n\n```yaml\nsteps:\n- uses: actions/checkout@v6\n- name: Setup dotnet\n uses: actions/setup-dotnet@v4\n with:\n dotnet-version: '6.x'\n cache: true\n- name: Install dependencies\n run: dotnet add package Newtonsoft.Json --version 12.0.1\n```\n\n> \\[!NOTE]\n> Je nach Anzahl der Abhängigkeiten ist es möglicherweise schneller, den Abhängigkeitscache zu verwenden. Bei Projekten mit vielen umfangreichen Abhängigkeiten sollte sich die Leistung erhöhen, da die zum Herunterladen erforderliche Zeit reduziert wird. Bei Projekten mit weniger Abhängigkeiten ist möglicherweise keine signifikante Leistungssteigerung, sondern aufgrund der Art und Weise, wie zwischengespeicherte Abhängigkeiten von NuGet installiert werden, sogar eine geringfügige Leistungsabnahme zu verzeichnen. Die Leistung variiert je nach Projekt.\n\n## Deinen Code bauen und testen\n\nDu kannst die gleichen Befehle verwenden, die Du auch lokal verwendest, um Deinen Code zu bauen und zu testen. In diesem Beispiel wird veranschaulicht, wie die Befehle `dotnet build` und `dotnet test` in einem Auftrag verwendet werden:\n\n```yaml\nsteps:\n- uses: actions/checkout@v6\n- name: Setup dotnet\n uses: actions/setup-dotnet@v4\n with:\n dotnet-version: '6.0.x'\n- name: Install dependencies\n run: dotnet restore\n- name: Build\n run: dotnet build --no-restore\n- name: Test with the dotnet CLI\n run: dotnet test --no-build\n```\n\n## Workflow-Daten als Artefakte paketieren\n\nNach Abschluss eines Workflows kannst du die resultierenden Artefakte für die Analyse hochladen. Zum Beispiel kann es notwendig sein, Logdateien, Core Dumps, Testergebnisse oder Screenshots zu speichern. Im folgenden Beispiel wird gezeigt, wie die Aktion `upload-artifact` zum Hochladen von Testergebnissen verwendet werden kann.\n\nWeitere Informationen finden Sie unter [Speichern und Freigeben von Daten mit Workflowartefakten](/de/actions/tutorials/store-and-share-data).\n\n```yaml\nname: dotnet package\n\non: [push]\n\njobs:\n build:\n\n runs-on: ubuntu-latest\n strategy:\n matrix:\n dotnet-version: [ '3.1.x', '6.0.x' ]\n\n steps:\n - uses: actions/checkout@v6\n - name: Setup dotnet\n uses: actions/setup-dotnet@v4\n with:\n dotnet-version: ${{ matrix.dotnet-version }}\n - name: Install dependencies\n run: dotnet restore\n - name: Test with dotnet\n run: dotnet test --no-restore --logger trx --results-directory \"TestResults-${{ matrix.dotnet-version }}\"\n - name: Upload dotnet test results\n uses: actions/upload-artifact@v4\n with:\n name: dotnet-results-${{ matrix.dotnet-version }}\n path: TestResults-${{ matrix.dotnet-version }}\n # Use always() to always run this step to publish test results when there are test failures\n if: ${{ always() }}\n```\n\n## In Paket-Registries veröffentlichen\n\nDu kannst deinen Workflow so konfigurieren, dass das .NET-Paket in einer Paketregistrierung veröffentlicht wird, wenn deine CI-Tests bestanden werden. Du kannst Repositorygeheimnisse verwenden, um alle Token oder Anmeldeinformationen zu speichern, die zum Veröffentlichen deiner Binärdatei erforderlich sind. Im folgenden Beispiel wird mit GitHub Packages ein Paket erstellt und in `dotnet core cli` veröffentlicht.\n\n```yaml\nname: Upload dotnet package\n\non:\n release:\n types: [created]\n\njobs:\n deploy:\n runs-on: ubuntu-latest\n permissions:\n packages: write\n contents: read\n steps:\n - uses: actions/checkout@v6\n - uses: actions/setup-dotnet@v4\n with:\n dotnet-version: '6.0.x' # SDK Version to use.\n source-url: https://nuget.pkg.github.com//index.json\n env:\n NUGET_AUTH_TOKEN: ${{secrets.GITHUB_TOKEN}}\n - run: dotnet build --configuration Release \n - name: Create the package\n run: dotnet pack --configuration Release \n - name: Publish the package to GPR\n run: dotnet nuget push /bin/Release/*.nupkg\n```"}