{"meta":{"title":"Création et test de code .NET","intro":"Découvrez comment créer un flux de travail d’intégration continue (CI) pour générer et tester votre projet .NET.","product":"GitHub Actions","breadcrumbs":[{"href":"/fr/actions","title":"GitHub Actions"},{"href":"/fr/actions/tutorials","title":"Tutoriels"},{"href":"/fr/actions/tutorials/build-and-test-code","title":"Générer et tester du code"},{"href":"/fr/actions/tutorials/build-and-test-code/net","title":".NET"}],"documentType":"article"},"body":"# Création et test de code .NET\n\nDécouvrez comment créer un flux de travail d’intégration continue (CI) pour générer et tester votre projet .NET.\n\n## Introduction\n\nCe guide explique comment générer, tester et publier un package .NET.\n\nLes exécuteurs hébergés dans GitHub ont un cache d’outils où sont préinstallés des logiciels, notamment le kit SDK .NET Core. Pour obtenir la liste complète des logiciels à jour et des versions préinstallées du SDK .NET Core, consultez [Logiciels installés sur les exécuteurs hébergés dans GitHub.](/fr/actions/using-github-hosted-runners/about-github-hosted-runners)\n\n## Prérequis\n\nVous devez déjà être familiarisé avec la syntaxe YAML et savoir comment elle s’utilise avec GitHub Actions. Pour plus d’informations, consultez « [Syntaxe de flux de travail pour GitHub Actions](/fr/actions/using-workflows/workflow-syntax-for-github-actions) ».\n\nIl est recommandé de connaître les bases du SDK .NET Core. Pour plus d’informations, consultez [Bien démarrer avec .NET](https://dotnet.microsoft.com/learn).\n\n## Utilisation d’un modèle de workflow .NET\n\nPour démarrer rapidement, ajoutez un modèle de workflow au répertoire `.github/workflows` de votre référentiel.\n\nGitHub fournit un modèle de workflow pour .NET qui devrait fonctionner pour la plupart des projets .NET. Les sections suivantes de ce guide donnent des exemples de la manière dont vous pouvez personnaliser ce modèle de workflow.\n\n1. Sur GitHub, accédez à la page principale du référentiel.\n\n2. Sous le nom de votre référentiel, cliquez sur ** Actions**.\n\n \n\n3. Si vous disposez déjà d’un workflow dans votre dépôt, cliquez sur **Nouveau workflow**.\n\n4. La page « Choisir un workflow » présente une sélection de modèles de workflow recommandés. Recherchez « dotnet ».\n\n5. Dans le flux de travail « .NET », cliquez sur **Configurer**.\n\n6. Modifiez le workflow en fonction des besoins. Par exemple, modifiez la version de .NET.\n\n7. Cliquez sur **Valider les changements**.\n\nLe fichier de workflow `dotnet.yml` est ajouté à l’annuaire `.github/workflows` de votre référentiel.\n\n## Spécification d’une version .NET\n\nPour utiliser une version préinstallée du SDK .NET Core sur un exécuteur hébergé dans GitHub, utilisez l’action `setup-dotnet`. Cette action recherche une version spécifique de .NET à partir du cache d’outils de chaque exécuteur, et ajoute les fichiers binaires nécessaires à `PATH`. Ces modifications seront conservées pendant toute la durée du travail.\n\nL’action `setup-dotnet` est recommandée pour l’utilisation de .NET avec GitHub Actions, car cela garantit un comportement cohérent sur tous les exécuteurs et toutes les versions de .NET. Si vous utilisez un exécuteur auto-hébergé, vous devez installer .NET et l’ajouter à `PATH`. Pour plus d’informations, consultez l’action [`setup-dotnet`](https://github.com/marketplace/actions/setup-net-core-sdk).\n\n### Utilisation de plusieurs versions de .NET\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### Utilisation d’une version spécifique de .NET\n\nVous pouvez configurer votre travail pour qu’il utilise une version spécifique de .NET, comme `6.0.22`. Vous pouvez également utiliser la syntaxe de versioning sémantique pour obtenir la dernière version mineure. Cet exemple utilise la dernière version mineure de .NET 6.\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## Installer les dépendances\n\nLe gestionnaire de package NuGet est installé sur les exécuteurs hébergés dans GitHub. Vous pouvez utiliser l’interface CLI dotnet pour installer des dépendances à partir du registre de package NuGet avant de générer et de tester votre code. Par exemple, le YAML ci-dessous installe le package `Newtonsoft`.\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### Mise en cache des dépendances\n\nVous pouvez mettre en cache les dépendances NuGet pour les flux de travail futurs à l’aide de l’entrée facultative `cache`. Par exemple, le YAML ci-dessous met en cache le dossier NuGet `global-packages`, puis installe le package `Newtonsoft`. Une deuxième entrée facultative, `cache-dependency-path`, peut être utilisée pour spécifier le chemin d’accès à un fichier de dépendance : `packages.lock.json`.\n\nPour plus d’informations, consultez « [Référence sur la mise en cache des dépendances](/fr/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> Selon le nombre de dépendances, il peut être plus rapide d’utiliser le cache des dépendances. Les projets qui ont de nombreuses dépendances doivent voir une amélioration des performances, car cela réduit le temps nécessaire au téléchargement. Les projets qui ont moins de dépendances peuvent ne pas constater d’amélioration significative des performances, et peuvent même voir une légère diminution de celles-ci en raison de la façon dont NuGet installe les dépendances mises en cache. Les performances varient d’un projet à l’autre.\n\n## Génération et test de votre code\n\nVous pouvez utiliser les mêmes commandes que celles que vous utilisez localement pour générer et tester votre code. Cet exemple montre comment utiliser `dotnet build` et `dotnet test` dans un travail :\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## Empaquetage des données de workflow en tant qu’artefacts\n\nUne fois le workflow terminé, vous pouvez charger les artefacts résultants à des fins d’analyse. Par exemple, vous devrez peut-être enregistrer des fichiers journaux, des vidages principaux, des résultats de test ou des captures d’écran. L’exemple suivant montre comment utiliser l’action `upload-artifact` pour charger les résultats de test.\n\nPour plus d’informations, consultez « [Stocker et partager des données avec les artefacts de workflow](/fr/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@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## Publication dans des registres de paquets\n\nVous pouvez configurer votre workflow pour publier votre package .NET dans un registre de package une fois vos tests CI réussis. Vous pouvez utiliser des secrets de dépôt pour stocker n’importe quels jetons ou informations d’identification nécessaires à la publication de votre fichier binaire. L’exemple suivant crée et publie un package dans GitHub Packages à l’aide de `dotnet core cli`.\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```"}