{"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/enterprise-server@3.16/actions","title":"GitHub Actions"},{"href":"/de/enterprise-server@3.16/actions/tutorials","title":"Anleitungen"},{"href":"/de/enterprise-server@3.16/actions/tutorials/build-and-test-code","title":"Erstellen und Testen von Code"},{"href":"/de/enterprise-server@3.16/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> \\[!NOTE]\n> Auf GitHub Enterprise Server gehostete Runner werden aktuell nicht auf GitHub unterstützt.\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 haben einen Toolcache mit vorinstallierter Software, die .NET Core SDK einschließt. Eine umfassende Liste mit aktueller Software und den vorinstallierten Versionen von .NET Core SDK findest du unter [Auf GitHub-gehosteten Runnern installierte Software](/de/enterprise-server@3.16/actions/using-github-hosted-runners/about-github-hosted-runners).\n\n## Voraussetzungen\n\nDu solltest bereits mit der YAML-Syntax vertraut sein und wissen, wie sie mit GitHub Actions verwendet wird. Weitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/enterprise-server@3.16/actions/using-workflows/workflow-syntax-for-github-actions).\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\nGitHub bietet eine Workflowvorlage für .NET, 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\n Wenn Sie die Workflowvorlage „.NET“ nicht finden, kopieren Sie den folgenden Workflowcode in eine neue Datei namens `dotnet.yml` im Verzeichnis `.github/workflows` Ihres Repositorys.\n\n ```yaml copy\n name: .NET\n\n on:\n push:\n branches: [ \"main\" ]\n pull_request:\n branches: [ \"main\" ]\n\n jobs:\n build:\n runs-on: ubuntu-latest\n\n steps:\n - uses: actions/checkout@v6\n - name: Setup .NET\n uses: actions/setup-dotnet@v4\n with:\n dotnet-version: 6.0.x\n - name: Restore dependencies\n run: dotnet restore\n - name: Build\n run: dotnet build --no-restore\n - name: Test\n run: dotnet test --no-build --verbosity normal\n ```\n\n6. Bearbeiten Sie den Workflow nach Bedarf. Ändern Sie beispielsweise die .NET-Version.\n\n7. Klicke auf **Änderungen übernehmen**.\n\n## Angeben einer .NET-Version\n\nVerwende die Aktion `setup-dotnet`, um eine vorinstallierte Version des .NET Core SDK für einen von GitHub gehosteten Runner zu verwenden. 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 Aktion `setup-dotnet` wird als Methode zur Verwendung von .NET mit GitHub Actions empfohlen, da damit ein konsistentes Verhalten bei verschiedenen Runnern und verschiedenen Version von .NET gewährleistet wird. 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\nAuf von GitHub gehosteten Runnern ist der Paketmanager NuGet 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/enterprise-server@3.16/actions/using-workflows/caching-dependencies-to-speed-up-workflows).\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/enterprise-server@3.16/actions/using-workflows/storing-workflow-data-as-artifacts).\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@v3\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 ein Paket erstellt und mithilfe von `dotnet core cli` in GitHub Packages 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```"}