Skip to main content

Diese Version von GitHub Enterprise wurde eingestellt am 2023-01-18. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für bessere Leistung, verbesserte Sicherheit und neue Features aktualisiere auf die neueste Version von GitHub Enterprise. Wende dich an den GitHub Enterprise-Support, um Hilfe zum Upgrade zu erhalten.

Erstellen und Testen eines .NET-Projekts

Du kannst einen Continuous-Integration-Workflow (CI) erstellen, um dein .NET-Projekt zu erstellen und zu testen.

Hinweis: GitHub-gehostete Runner werden auf GitHub Enterprise Server derzeit nicht unterstützt. Weitere Informationen zur geplanten zukünftigen Unterstützung findest Du in der GitHub public roadmap.

Einführung

In dieser Anleitung erfährst du, wie du ein .NET-Paket erstellst, testest und veröffentlichst.

GitHub gehostete Runner verfügen über einen Toolcache mit vorinstallierter Software, in dem das .NET Core SDK enthalten ist. Eine umfassende Liste mit aktueller Software und den vorinstallierten Versionen von .NET Core SDK findest du unter Auf GitHub-gehosteten Runnern installierte Software.

Voraussetzungen

Du solltest bereits mit der YAML-Syntax vertraut sein und wissen, wie sie mit GitHub Actions verwendet wird. Weitere Informationen findest du unter Workflowsyntax für GitHub Actions.

Du solltest über grundlegende Kenntnisse in Bezug auf das .NET Core SDK verfügen. Weitere Informationen findest du unter Erste Schritte mit .NET.

Verwenden des .NET-Starterworkflows

Von GitHub wird ein .NET-Starterworkflow bereitgestellt, der für die meisten .NET-Projekte verwendet werden kann. Wie du diesen Starterworkflow anpassen kannst, erfährst du anhand der Beispiele in diesem Leitfaden. Weitere Informationen findest du im .NET-Starterworkflow.

Für einen schnellen Einstieg fügst du den Starterworkflow zum Verzeichnis .github/workflows deines Repositorys hinzu.

name: dotnet package

on: [push]

jobs:
  build:

    runs-on: ubuntu-latest
    strategy:
      matrix:
        dotnet-version: ['3.0', '3.1.x', '5.0.x' ]

    steps:
      - uses: actions/checkout@v2
      - name: Setup .NET Core SDK ${{ matrix.dotnet-version }}
        uses: actions/setup-dotnet@v1
        with:
          dotnet-version: ${{ matrix.dotnet-version }}
      - name: Install dependencies
        run: dotnet restore
      - name: Build
        run: dotnet build --configuration Release --no-restore
      - name: Test
        run: dotnet test --no-restore --verbosity normal

Angeben einer .NET-Version

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

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

Verwenden mehrerer .NET-Versionen

name: dotnet package

on: [push]

jobs:
  build:

    runs-on: ubuntu-latest
    strategy:
      matrix:
        dotnet-version: [ '3.0', '3.1.x', '5.0.x' ]

    steps:
      - uses: actions/checkout@v2
      - name: Setup dotnet ${{ matrix.dotnet-version }}
        uses: actions/setup-dotnet@v1
        with:
          dotnet-version: ${{ matrix.dotnet-version }}
      # You can test your matrix by printing the current dotnet version
      - name: Display dotnet version
        run: dotnet --version

Verwenden einer bestimmten .NET-Version

Du kannst einen Auftrag so konfigurieren, dass eine bestimmte Version von .NET verwendet wird, z. B. 3.1.3. Alternativ kannst du auch Syntax für semantische Versionierung verwenden, um die neuste Nebenversion abzurufen. In diesem Beispiel wird die neueste Nebenversion von .NET 3 verwendet.

    - name: Setup .NET 3.x
      uses: actions/setup-dotnet@v1
      with:
        # Semantic version range syntax or exact version of a dotnet version
        dotnet-version: '3.x'

Installieren von Abhängigkeiten

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

steps:
- uses: actions/checkout@v2
- name: Setup dotnet
  uses: actions/setup-dotnet@v1
  with:
    dotnet-version: '3.1.x'
- name: Install dependencies
  run: dotnet add package Newtonsoft.Json --version 12.0.1

Deinen Code bauen und testen

Du 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:

steps:
- uses: actions/checkout@v2
- name: Setup dotnet
  uses: actions/setup-dotnet@v1
  with:
    dotnet-version: '3.1.x'
- name: Install dependencies
  run: dotnet restore
- name: Build
  run: dotnet build
- name: Test with the dotnet CLI
  run: dotnet test

Workflow-Daten als Artefakte paketieren

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

Weitere Informationen findest du unter Speichern von Workflowdaten mithilfe von Artefakten.

name: dotnet package

on: [push]

jobs:
  build:

    runs-on: ubuntu-latest
    strategy:
      matrix:
        dotnet-version: [ '3.0', '3.1.x', '5.0.x' ]

      steps:
        - uses: actions/checkout@v2
        - name: Setup dotnet
          uses: actions/setup-dotnet@v1
          with:
            dotnet-version: ${{ matrix.dotnet-version }}
        - name: Install dependencies
          run: dotnet restore
        - name: Test with dotnet
          run: dotnet test --logger trx --results-directory "TestResults-${{ matrix.dotnet-version }}"
        - name: Upload dotnet test results
          uses: actions/upload-artifact@v2
          with:
            name: dotnet-results-${{ matrix.dotnet-version }}
            path: TestResults-${{ matrix.dotnet-version }}
          # Use always() to always run this step to publish test results when there are test failures
          if: ${{ always() }}

In Paket-Registries veröffentlichen

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

name: Upload dotnet package

on:
  release:
    types: [created]

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      packages: write
      contents: read
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-dotnet@v1
        with:
          dotnet-version: '3.1.x' # SDK Version to use.
          source-url: https://nuget.pkg.github.com/<owner>/index.json
        env:
          NUGET_AUTH_TOKEN: ${{secrets.GITHUB_TOKEN}}
      - run: dotnet build --configuration Release <my project>
      - name: Create the package
        run: dotnet pack --configuration Release <my project>
      - name: Publish the package to GPR
        run: dotnet nuget push <my project>/bin/Release/*.nupkg