Générer, tester et déployer des projets .NET Core

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

Cet article explique comment utiliser Azure Pipelines pour utiliser des projets .NET Core. L’article vous guide tout au long des tâches suivantes :

• Créez une application web .NET Core et chargez-la dans un dépôt GitHub.
• Créez un projet Azure DevOps et un pipeline Azure Pipelines pour générer le projet.
• Configurez votre environnement de build avec des agents hébergés par Microsoft ou auto-hébergés.
• Restaurez les dépendances, générez votre projet et testez avec la tâche .NET Core (DotNetCoreCLI@2) ou un script.
• Utilisez la tâche .NET Core () pour ajouter d’autres commandes du Kit de développement logiciel (DotNetCoreCLI@2SDK) .NET à votre pipeline.
• Utilisez la tâche Publier les résultats de couverture du code (Publish code coverage results v2) pour publier les résultats de couverture du code.
• Empaqueter et remettre votre sortie de build à votre pipeline, un flux NuGet, une archive ZIP ou d’autres cibles.

Remarque

Pour utiliser des projets .NET Framework, consultez Générer des applications ASP.NET avec .NET Framework.

Prérequis

Pour effectuer toutes les procédures décrites dans cet article, vous avez besoin des prérequis suivants :

• Une organisation Azure DevOps. Vous pouvez en créer un gratuitement.
• L’appartenance au groupe Administrateurs de projet de l’organisation vous permet de créer des projets Azure DevOps et d’accorder l’accès au projet aux pipelines. Les propriétaires d’organisations Azure DevOps ont automatiquement cette appartenance.
• Un projet Azure DevOps dans l’organisation. Créez un projet dans Azure DevOps.
• Possibilité d’exécuter des pipelines sur des agents hébergés par Microsoft, en demandant un niveau gratuit de travaux parallèles. Cette demande peut prendre plusieurs jours ouvrables pour traiter. Pour plus d’informations, consultez Configurer et payer des travaux parallèles.
• Rôle Administrateur ou Créateur pour les connexions de service, que vous pouvez attribuer en tant qu’administrateur de projet.
• Un compte et un référentiel GitHub .

Créer un projet .NET et le charger sur GitHub

Si vous souhaitez utiliser un projet .NET déjà dans votre dépôt GitHub, vous pouvez ignorer cette section.

Si vous n’avez pas de projet .NET à utiliser, créez-en un sur votre ordinateur local comme suit :

1. Installez le Kit de développement logiciel (SDK) .NET 8.0 ou vérifiez qu’il est installé.
2. Ouvrez une fenêtre de terminal sur votre ordinateur local.
3. Créer un répertoire de projet et y accéder.
4. Créez une application web .NET 8 en exécutant dotnet new webapp -f net8.0.
5. Générez et exécutez l’application localement à l’aide dotnet runde .
6. Lorsque l’application démarre, appuyez sur Ctrl+C pour l’arrêter.
7. Chargez ou connectez le projet local à votre dépôt GitHub.

Créer une chaîne de traitement

Si vous avez un pipeline que vous souhaitez utiliser, vous pouvez ignorer cette section. Sinon, vous pouvez utiliser l’éditeur de pipeline YAML ou l’éditeur classique pour créer un pipeline comme suit :

YAML

1. Dans votre projet Azure DevOps, sélectionnez Pipelines dans le menu de navigation de gauche.

2. Sélectionnez Nouveau pipeline ou Créer un pipeline si ce pipeline est le premier dans le projet.

3. Dans l’écran Où se trouve votre code , sélectionnez GitHub.

4. Vous serez peut-être redirigé vers GitHub pour vous connecter. Si c’est le cas, entrez vos informations d’identification GitHub.

5. Dans l’écran Sélectionner un référentiel , sélectionnez le référentiel dans lequel se trouve votre application .NET.

6. Vous serez peut-être redirigé vers GitHub pour pouvoir installer l’application Azure Pipelines. Si c’est le cas, sélectionnez Approuver et installer.

7. Sous l’onglet Configurer , sélectionnez Afficher plus , puis sélectionnez le modèle de pipeline principal ASP.NET dans la liste. Ce modèle fournit de nombreuses étapes et paramètres décrits par cet article.

   Vous pouvez également sélectionner le pipeline Starter sous l’onglet Configurer pour commencer par un pipeline minimal et ajouter vous-même les étapes et paramètres.

8. Sous l’onglet Révision , examinez le code YAML. Vous pouvez personnaliser le fichier pour vos besoins. Par exemple, vous pouvez spécifier un pool d’agents différent ou ajouter une tâche pour installer un autre SDK .NET.

9. Lorsque vous êtes prêt, sélectionnez Enregistrer et exécuter.

   

10. Modifiez éventuellement le message De validation, puis sélectionnez Enregistrer et réexécuter .

11. Sous l’onglet Résumé , sélectionnez le travail dans la section Travaux pour surveiller votre pipeline en action.

Classique

1. Dans votre projet Azure DevOps, sélectionnez Pipelines dans le menu de navigation de gauche.

2. Sélectionnez Nouveau pipeline ou Créer un pipeline si ce pipeline est le premier dans le projet.

3. Dans l’écran Où se trouve votre code , sélectionnez Utiliser l’éditeur classique pour créer un pipeline sans YAML.

   Remarque

   La possibilité de créer des pipelines classiques est désactivée par défaut pour les nouvelles organisations et projets Azure DevOps. Si vous ne voyez pas l’option permettant d’utiliser l’éditeur classique, désactivez la création de pipelines de build classiques et désactivez la création d’options de pipelines de mise en production classiques dans les paramètresdes pipelines>des paramètres de l’organisation > et/oules> du projet>

4. Sous Sélectionner une source, sélectionnez GitHub.

5. Fournissez un nom de connexion, puis sélectionnez Autoriser à l’aide d’OAuth. Vous pouvez également choisir d’autoriser avec l’application GitHub Azure Pipelines ou un jeton d’accès personnel GitHub GitHub (PAT).

6. Fournissez le nom de votre dépôt GitHub, y compris l’organisation ou l’utilisateur, et votre branche par défaut, généralement principale.

7. Sélectionnez Continuer.

8. Dans l’écran Sélectionner un modèle , recherchez et sélectionnez le modèle ASP.NET Core , puis sélectionnez Appliquer. La page de pipeline s’ouvre, où vous pouvez ajouter des tâches, spécifier des pools d’agents et des agents, et configurer d’autres options de génération.

   Le modèle ASP.NET Core fournit de nombreuses étapes et paramètres décrits par cet article. Vous pouvez également sélectionner Un travail vide pour commencer par un pipeline minimal et ajouter vous-même les tâches et les paramètres.

9. Sous l’onglet Tâches , sous Pool d’agents, sélectionnez Azure Pipelines pour utiliser des agents hébergés par Microsoft.

10. Sous Spécification de l’agent, sélectionnez windows-latest pour cet exemple.

11. Sélectionnez Enregistrer et file d’attente Enregistrer> en haut de la page.

12. Dans l’écran Exécuter le pipeline , entrez un commentaire Enregistrer, puis sélectionnez Enregistrer et exécuter.

13. Sélectionnez le travail dans la section Travaux de l’onglet Résumé pour afficher votre pipeline en action.

Vous pouvez ajouter des tâches au travail agent 1 en sélectionnant le travail et en sélectionnant + une tâche dans la liste. Par exemple, vous pouvez ajouter la tâche Use .NET Core comme première tâche pour installer le Kit de développement logiciel (SDK) .NET.

Vous disposez maintenant d’un pipeline de travail prêt à être personnalisé.

Configurez votre environnement de build

Vous pouvez créer vos projets .NET Core à l’aide du Kit de développement logiciel (SDK) .NET Core et du runtime pour Windows, Linux ou macOS. Par défaut, vos builds s’exécutent sur des agents hébergés par Microsoft. Vous n’avez donc pas besoin de configurer l’infrastructure.

Les agents hébergés par Microsoft Azure Pipelines incluent plusieurs versions préinstallées des kits SDK .NET Core pris en charge. Pour obtenir la liste complète des images disponibles et des exemples de configuration, consultez les agents hébergés par Microsoft .

L’extrait de code de pipeline YAML suivant définit le système d’exploitation Ubuntu pour le pool d’agents.

pool:
  vmImage: 'ubuntu-latest' 

Les agents hébergés par Microsoft n’incluent pas certaines versions antérieures du Kit de développement logiciel (SDK) .NET Core et n’incluent généralement pas de versions préliminaires. Si vous avez besoin de ces versions du Kit de développement logiciel (SDK) sur les agents hébergés par Microsoft, vous pouvez les installer à l’aide de la tâche Utiliser DotNet (UseDotNet@2).

Par exemple, le code suivant installe le Kit de développement logiciel (SDK) .NET 5.0.x :

steps:
- task: UseDotNet@2
  inputs:
    version: '5.x'

Les agents Windows incluent déjà un runtime .NET Core. Pour installer un sdk plus récent, définissez performMultiLevelLookup comme true dans l’extrait de code suivant :

steps:
- task: UseDotNet@2
  displayName: 'Install .NET Core SDK'
  inputs:
    version: 8.x
    performMultiLevelLookup: true
    includePreviewVersions: true # Required for preview versions

Agents auto-hébergés

Vous pouvez également utiliser des agents auto-hébergés pour générer vos projets .NET Core. Vous pouvez configurer des agents auto-hébergés Linux, macOS ou Windows .

Les agents auto-hébergés vous permettent de :

• Évitez le coût d’exécution du programme d’installation de l’outil UseDotNet@2 .
• Réduisez le temps de génération si vous disposez d’un dépôt volumineux.
• Exécutez des builds incrémentielles.
• Utilisez des sdk en préversion ou privés que Microsoft ne prend pas officiellement en charge.
• Utilisez des kits SDK disponibles uniquement sur vos environnements d’entreprise ou locaux.

Pour plus d’informations, consultez Agents hébergés localement.

Restaurer les dépendances

Les packages NuGet permettent à votre projet de dépendre du code que vous ne générez pas. Vous pouvez télécharger des packages NuGet et des outils spécifiques au projet en exécutant la dotnet restore commande, via la tâche .NET Core (DotNetCoreCLI@2) ou en tant que script dans votre pipeline. La dotnet restore commande utilise le NuGet.exe empaqueté avec le Kit de développement logiciel (SDK) .NET Core et ne peut restaurer que les packages spécifiés dans les fichiers *.csproj du projet .NET Core.

Vous pouvez utiliser la tâche .NET Core (DotNetCoreCLI@2) pour télécharger et restaurer des packages NuGet à partir d’Azure Artifacts, de NuGet.org ou d’un autre référentiel NuGet externe ou interne authentifié. Si le flux NuGet se trouve dans le même projet que votre pipeline, vous n’avez pas besoin de vous authentifier. Pour plus d’informations, veuillez consulter la section .NET Core task (DotNetCoreCLI@2).

Lorsque vous utilisez des agents hébergés par Microsoft, vous obtenez une nouvelle machine à chaque fois que vous exécutez une build, ce qui restaure les paquets à chaque exécution. La restauration peut prendre beaucoup de temps. Pour atténuer ce problème, utilisez Azure Artifacts ou un agent auto-hébergé pour tirer parti du cache de package.

Le pipeline suivant utilise la DotNetCoreCLI@2 tâche pour restaurer un flux Azure Artifact.

trigger:
- main

pool:
  vmImage: 'windows-latest'

steps:
- task: UseDotNet@2
  displayName: 'Install .NET Core SDK'
  inputs:
    version: 8.x
    performMultiLevelLookup: true
    includePreviewVersions: true # Required for preview versions

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)'

Dans le Kit de développement logiciel (SDK) .NET Core version 2.0 et ultérieure, les packages sont restaurés automatiquement lorsque vous exécutez des commandes telles que dotnet build. Vous devez toujours utiliser la tâche .NET Core (DotNetCoreCLI@2) pour restaurer des packages si vous utilisez un flux authentifié.

Gérez les informations d’identification d’un flux authentifié en créant une connexion de service NuGet dans lesconnexions de service>>de projet. Pour plus d’informations sur les connexions de service NuGet, consultez Publier des packages NuGet avec Azure Pipelines.

Restaurer des packages à partir de NuGet.org

Pour restaurer des packages à partir de NuGet.org, mettez à jour votre pipeline comme suit.

YAML

Vous pouvez ajouter la commande de restauration à votre pipeline en modifiant directement le code YAML ou à l’aide de l’Assistant Tâche.

Ajoutez directement la tâche .NET Core (DotNetCoreCLI@2) en insérant l’extrait de code suivant dans votre fichier azure-pipelines.yml avant vos tâches de génération.

steps:
- task: DotNetCoreCLI@2
  displayName: Restore
  inputs:
    command: restore
    projects: '**/*.csproj'
    feedsToUse: select

Pour utiliser l’assistant de tâche :

1. Allez à la position dans le fichier YAML où vous souhaitez insérer la tâche.
2. Sélectionnez .NET Core dans le catalogue de tâches.
3. Dans l’écran de configuration, sélectionnez restaurer dans la liste déroulante Commandes .
4. Dans le champ Chemin d’accès aux projets ou solutions , entrez le chemin d’accès à vos fichiers *.csproj . Vous pouvez utiliser le caractère générique **/*.csproj pour tous les fichiers *.csproj dans tous les sous-dossiers.
5. Pour que les flux soient ajoutés, vérifiez que le ou les flux que je sélectionne ici et utilisez des packages à partir de NuGet.org sont sélectionnés.
6. Sélectionnez Ajouter.
7. Sélectionnez Valider et enregistrer, puis sélectionnez Enregistrer pour valider la modification.

Classique

Vous pouvez ajouter une tâche de restauration à l’aide de l’éditeur classique.

1. Sous l’onglet Tâches de votre pipeline, sélectionnez Le travail de l’agent 1 ou un autre travail qui exécute vos tâches de génération.
2. Sélectionnez + pour ajouter une nouvelle tâche à ce travail.
3. Dans le catalogue de tâches, sélectionnez .NET Core , puis sélectionnez Ajouter.
4. Dans le volet gauche, sélectionnez la tâche de génération dotnet ajoutée pour ouvrir l’éditeur de tâche.
5. Sélectionnez restaurer dans la liste déroulante Commandes . Le nom d’affichage passe à dotnet restore.
6. Dans le champ Chemin d’accès aux projets ou solutions , entrez le chemin d’accès à vos fichiers *.csproj . Vous pouvez utiliser le caractère générique **/*.csproj pour tous les fichiers *.csproj dans tous les sous-dossiers.
7. Pour que les flux soient ajoutés, vérifiez que le ou les flux que je sélectionne ici et utilisez des packages à partir de NuGet.org sont sélectionnés.
8. Dans le volet gauche, faites glisser la tâche pour la positionner avant la tâche de génération .
9. En haut de la page, sélectionnez Enregistrer et enregistrer la file d’attente>.

Restaurez les paquets depuis un flux externe

Pour spécifier un référentiel NuGet externe, placez l’URL dans un fichier NuGet.config dans votre dépôt. Vérifiez que tout flux personnalisé est spécifié dans votre fichier NuGet.config et que les informations d’identification sont spécifiées dans une connexion de service NuGet.

Pour restaurer des packages à partir d’un flux externe, ajoutez la restore tâche comme indiqué dans la section précédente, mais modifiez les paramètres de configuration comme suit :

YAML

Ajoutez directement la tâche .NET Core (DotNetCoreCLI@2) en insérant l’extrait de code suivant dans votre fichier azure-pipelines.yml avant vos tâches de génération. Remplacez par <NuGet service connection> le nom de votre connexion de service.

steps:
- task: DotNetCoreCLI@2
  displayName: Restore
  inputs:
    command: restore
    projects: '**/*.csproj'
    feedsToUse: config
    nugetConfigPath: NuGet.config    # Relative to root of the repository
    externalFeedCredentials: <NuGet service connection>

Pour utiliser l’assistant de tâche :

1. Ajoutez la tâche .NET Core et sélectionnez restaurer sur l’écran de configuration comme dans la procédure précédente.
2. Pour ajouter des flux, sélectionnez Flux dans mon NuGet.config.
3. Sous Chemin d’accès à NuGet.config, entrez le chemin d’accès à votre fichier NuGet.config , par rapport à la racine de votre référentiel. Vous pouvez sélectionner les points de suspension ... en regard du champ pour parcourir et sélectionner l’emplacement.
4. Sous Informations d’identification pour les flux en dehors de cette organisation/collection, sélectionnez les informations d’identification à utiliser pour les registres externes dans le fichier NuGet.config sélectionné. Pour les flux de la même organisation, vous pouvez laisser ce champ vide. Les informations d’identification de la build sont utilisées automatiquement.

Classique

1. Ajoutez la tâche .NET Core et sélectionnez restaurer sur l’écran de configuration.

2. Pour ajouter des flux, sélectionnez Flux dans mon NuGet.config.

3. Sous Chemin d’accès à NuGet.config, entrez le chemin d’accès à votre fichier NuGet.config , par rapport à la racine de votre référentiel. Vous pouvez sélectionner les points de suspension ... pour accéder à l’emplacement du référentiel et le sélectionner.

4. Sous Informations d’identification pour les flux en dehors de cette organisation/collection, sélectionnez les informations d’identification à utiliser pour les registres externes situés dans le NuGet.configsélectionné. Pour les flux de cette organisation, vous pouvez laisser ce champ vide, car les informations d’identification de la build sont utilisées automatiquement.

   Vous pouvez sélectionner Gérer pour accéder aux paramètres de votre projet et sélectionner la connexion. Vous pouvez également sélectionner Nouveau pour créer une connexion de service. Veillez à cocher la case à cocher Accorder l’autorisation d’accès à tous les pipelines.

Restaurer des packages pour les projets .NET Framework

Si vous avez également un projet Microsoft .NET Framework dans votre solution ou que vous utilisez package.json pour spécifier vos dépendances, utilisez la tâche NuGetCommand@2 pour restaurer ces dépendances.

- task: NuGetCommand@2
  inputs:
    command: 'restore'
    restoreSolution: '**/*.sln'
    feedsToUse: 'select'

Remarque

Pour Ubuntu 24.04 ou version ultérieure, vous devez utiliser la tâche NuGetAuthenticate au lieu de la tâche NuGetCommand@2 avec l’interface CLI .NET. Pour plus d’informations, consultez Prise en charge des images hébergées Ubuntu plus récentes.

Générer votre projet

Générez votre projet .NET Core en exécutant la dotnet build commande. Vous pouvez ajouter la commande à votre pipeline à l’aide de la tâche .NET Core (DotNetCoreCLI@2) ou en tant que script de ligne de commande.

Utiliser la tâche .NET Core

YAML

Vous pouvez ajouter une tâche de génération avec l’éditeur de pipeline YAML en modifiant directement le fichier ou en utilisant l’Assistant Tâche.

Ajoutez directement la tâche .NET Core (DotNetCoreCLI@2) en insérant l’extrait de code suivant. Mettez à jour les arguments éléments correspondant à vos besoins.

steps:
- task: DotNetCoreCLI@2
  displayName: Build
  inputs:
    command: build
    projects: '**/*.csproj'
    arguments: '--configuration $(buildConfiguration)'

Pour utiliser l’assistant de tâche :

1. Allez à la position dans le fichier YAML où vous souhaitez insérer la tâche.
2. Sélectionnez la tâche .NET Core (DotNetCoreCLI@2).
3. Sélectionnez build dans la liste déroulante Commandes .
4. Dans le champ Chemin d’accès aux projets ou solutions , entrez le chemin d’accès à vos fichiers *.csproj . Vous pouvez utiliser le caractère générique **/*.csproj pour tous les fichiers *.csproj dans tous les sous-dossiers.
5. Sélectionnez Ajouter.
6. Sélectionnez Sauvegarder pour valider le changement.

Classique

Vous pouvez ajouter une tâche de génération à l’aide de l’éditeur classique.

1. Sous l’onglet Tâches de votre pipeline, sélectionnez Le travail de l’agent 1 ou un autre travail qui exécute vos tâches de génération.
2. Sélectionnez + pour ajouter une nouvelle tâche à ce travail.
3. Dans le catalogue de tâches, sélectionnez .NET Core , puis sélectionnez Ajouter.
4. Dans le volet gauche, sélectionnez la tâche de génération dotnet ajoutée pour ouvrir l’éditeur de tâche. Le champ Commande affiche déjà la génération.
5. Dans le champ Chemin d’accès aux projets ou solutions , entrez le chemin d’accès à vos fichiers *.csproj . Vous pouvez utiliser le caractère générique **/*.csproj pour tous les fichiers *.csproj dans tous les sous-dossiers.
6. Pour que les flux soient ajoutés, vérifiez que le ou les flux que je sélectionne ici et utilisez des packages à partir de NuGet.org sont sélectionnés.
7. Dans le volet gauche, faites glisser la tâche pour la positionner dans la séquence de tâches appropriée.
8. En haut de la page, sélectionnez Enregistrer et enregistrer la file d’attente>.

Générer .NET Core avec un script de ligne de commande

Vous pouvez également générer à l’aide d’un script de ligne de commande.

YAML

Pour ajouter une ligne de commande de build en modifiant directement le fichier YAML, ajoutez le code suivant :

steps:
- script: dotnet build --configuration $(buildConfiguration)
  displayName: 'dotnet build $(buildConfiguration)'

Vous pouvez également utiliser l’Assistant Tâche pour ajouter la tâche de ligne de commande .

1. Allez à la position dans le fichier YAML où vous souhaitez insérer la tâche.
2. Sélectionnez la tâche de ligne de commande (CmdLine@2) dans la liste.
3. Dans le champ Script , entrez la dotnet build commande avec des paramètres. Par exemple : dotnet build --configuration $(buildConfiguration).
4. Sous Répertoire detravail>, entrez le chemin d’accès au fichier *.csproj en tant que répertoire de travail. Si vous le laissez vide, le répertoire de travail est défini par défaut $(Build.SourcesDirectory)sur .
5. Sélectionnez Ajouter.
6. Sélectionnez Sauvegarder pour valider le changement.

Classique

Pour ajouter une ligne de commande de build à l’aide de l’éditeur classique :

1. Sous l’onglet Tâches de votre pipeline, sélectionnez Le travail de l’agent 1 ou un autre travail qui exécute vos tâches de génération.
2. Sélectionnez + pour ajouter une nouvelle tâche à ce travail.
3. Dans le catalogue de tâches, sélectionnez Ligne de commande , puis Ajouter.
4. Dans le volet gauche, sélectionnez la tâche de script de ligne de commande ajoutée pour ouvrir l’éditeur de tâches.
5. Modifiez le nom d’affichage si vous le souhaitez.
6. Sous Script, entrez la dotnet build commande avec des paramètres. Par exemple : dotnet build --configuration $(buildConfiguration).
7. Sous Répertoire detravail>, entrez le chemin d’accès au fichier *.csproj en tant que répertoire de travail. Vous pouvez sélectionner les points de suspension ... pour accéder à l’emplacement du référentiel et le sélectionner.
8. Dans le volet gauche, faites glisser la tâche pour la positionner dans la séquence de tâches appropriée.
9. En haut de la page, sélectionnez Enregistrer et enregistrer la file d’attente>.

Ajouter d’autres commandes du Kit de développement logiciel (SDK) .NET à votre pipeline

Vous pouvez ajouter d’autres commandes du Kit de développement logiciel (SDK) .NET à votre pipeline à l’aide de la tâche .NET Core (DotNetCoreCLI@2) ou en tant que scripts.

Ajouter une commande CLI .NET avec la tâche .NET Core

La tâche .NET Core (DotNetCoreCLI@2) vous permet d’ajouter facilement des commandes CLI .NET à votre pipeline. Vous pouvez ajouter des tâches .NET Core (DotNetCoreCLI@2) en modifiant votre fichier YAML ou en utilisant l’éditeur classique.

YAML

Pour ajouter une commande .NET Core à l’aide de l’Assistant tâche dans l’éditeur de pipeline YAML, procédez comme suit :

1. Allez à la position dans le fichier YAML où vous souhaitez insérer la tâche.
2. Sélectionnez .NET Core dans le catalogue de tâches.
3. Sélectionnez la commande que vous souhaitez exécuter dans la liste déroulante dans le champ Commande .
4. Configurez toutes les options nécessaires.
5. Sélectionnez Ajouter.
6. Sélectionnez Sauvegarder pour valider le changement.

Ajouter une commande CLI .NET Core dans un script

Vous pouvez ajouter une commande CLI .NET Core en tant que script dans votre fichier azure-pipelines.yml . Par exemple:

steps:
# ...
- script: dotnet test <test-project> 

Classique

Pour ajouter une commande .NET Core à l’aide de l’éditeur classique, procédez comme suit :

1. Sous l’onglet Tâches de votre pipeline, sélectionnez Le travail de l’agent 1 ou un autre travail qui exécute vos tâches de génération.
2. Sélectionnez + pour ajouter une nouvelle tâche à ce travail.
3. Dans le catalogue de tâches, sélectionnez .NET Core , puis sélectionnez Ajouter.
4. Dans le volet gauche, sélectionnez la tâche de génération dotnet ajoutée pour ouvrir l’éditeur de tâche.
5. Modifiez le nom d’affichage comme vous le souhaitez. Le nom de la tâche dans le volet gauche est mis à jour en conséquence.
6. Sous Commande, sélectionnez la commande que vous souhaitez exécuter, par exemple personnalisée.
7. Configurez toutes les options nécessaires.
8. Dans le volet gauche, faites glisser la tâche pour la positionner dans la séquence de tâches appropriée.
9. En haut de la page, sélectionnez Enregistrer et enregistrer la file d’attente>.

Installer un outil

Pour installer un outil global .NET Core comme dotnetsay dans une build exécutée sur Windows, ajoutez une tâche .NET Core et définissez les propriétés suivantes dans la configuration :

• Commande : personnalisée
• Chemin d’accès aux projets : laissez vide
• Commande personnalisée : tool
• Arguments : install -g dotnetsay

Pour exécuter l’outil, ajoutez une tâche de ligne de commande et entrez dotnetsay dans le champ Script .

Exécutez vos tests.

Lorsque vous avez des projets de test dans votre référentiel, vous pouvez utiliser la tâche .NET Core (DotNetCoreCLI@2) pour exécuter des tests unitaires à l’aide de frameworks de test tels que MSTest, xUnit et NUnit. Le projet de test doit référencer Microsoft.NET.Test.SDK version 15.8.0 ou ultérieure.

Les résultats des tests publient automatiquement sur le service et sont disponibles dans le résumé de la build. Vous pouvez utiliser les résultats des tests pour résoudre les échecs des tests et analyser le minutage des tests.

Pour ajouter une tâche de test à votre pipeline, ajoutez l’extrait de code suivant à votre fichier azure-pipelines.yml :

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

Si vous utilisez l’Assistant Tâche pour ajouter la tâche .NET Core (DotNetCoreCLI@2), définissez les propriétés suivantes :

• Commande : test
• Chemin d’accès aux projets : définir les projets de test dans votre solution
• Arguments : --configuration $(BuildConfiguration)

Vous pouvez également exécuter la dotnet test commande avec un enregistreur d’événements spécifique, puis utiliser la PublishTestResults@2 tâche :

steps:
# ...
# do this after your tests run
- script: dotnet test <test-project> --logger trx
- task: PublishTestResults@2
  condition: succeededOrFailed()
  inputs:
    testRunner: VSTest
    testResultsFiles: '**/*.trx'

Collecter la couverture du code

Lorsque vous générez sur la plateforme Windows, vous pouvez collecter des métriques de couverture de code à l’aide du collecteur de données de couverture intégré. Le projet de test doit référencer Microsoft.NET.Test.SDK version 15.8.0 ou ultérieure.

Lorsque vous utilisez la tâche .NET Core (DotNetCoreCLI@2) pour exécuter des tests, les données de couverture publient automatiquement sur le serveur. Vous pouvez télécharger le fichier *.coverage à partir du résumé de build pour afficher dans Visual Studio.

Pour collecter la couverture du code, ajoutez l’argument --collect "Code Coverage" lorsque vous ajoutez la tâche de test à votre pipeline.

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

Si vous utilisez l’Assistant Tâche pour ajouter la tâche .NET Core (DotNetCoreCLI@2), définissez les propriétés suivantes :

• Commande : test
• Chemin d’accès aux projets : définir les projets de test dans votre solution
• Arguments : --configuration $(BuildConfiguration) --collect "Code Coverage"

Vérifiez que l’option Publier les résultats des tests reste sélectionnée.

Vous pouvez également collecter les résultats de couverture du code à l’aide de la dotnet test commande avec un enregistreur d’événements spécifique, puis exécuter la tâche PublishTestResults@2 , utilisez le code suivant :

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

Collecter des métriques de couverture du code avec Coverlet

Si vous générez sur Linux ou macOS, vous pouvez utiliser Coverlet ou un outil similaire pour collecter les métriques de couverture du code.

Vous pouvez publier des résultats de couverture du code sur le serveur avec la tâche Publier les résultats de la couverture du code (PublishCodeCoverageResults@2). Vous devez configurer l’outil de couverture pour générer des résultats au format de couverture Cobertura ou JaCoCo.

Pour exécuter des tests et publier la couverture du code avec Coverlet :

1. Ajoutez une référence au package NuGet coverlet.collector.
2. Ajoutez l’extrait de code suivant à votre fichier azure-pipelines.yml :

- 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 project directory>'
  
- task: PublishCodeCoverageResults@2
  displayName: 'Publish code coverage report'
  inputs:
    codeCoverageTool: 'Cobertura'
    summaryFileLocation: '$(Agent.TempDirectory)/**/coverage.cobertura.xml'

Empaqueter et remettre votre code

Pour empaqueter et fournir votre sortie de build, vous pouvez :

• Publiez vos artefacts de build sur Azure Pipelines.
• Créez un package NuGet et publiez-le dans votre flux NuGet.
• Publiez votre package NuGet sur Azure Artifacts.
• Créez une archive ZIP à déployer sur une application web.
• Publiez des symboles sur un serveur de symboles Azure Artifacts ou un partage de fichiers.

Vous pouvez également construire une image pour votre application et la pousser vers un registre de conteneurs.

Publier des artefacts sur Azure Pipelines

Pour publier la sortie de votre build .NET sur votre pipeline, procédez comme suit.

1. Exécutez à dotnet publish --output $(Build.ArtifactStagingDirectory) l’aide de l’interface CLI .NET ou ajoutez la tâche .NET Core (DotNetCoreCLI@2) avec la commande de publication .
2. Publiez l’artefact à l’aide de la tâche Publish Pipeline Artifact (PublishPipelineArtifact@1). Cette tâche charge tous les fichiers dans $(Build.ArtifactStagingDirectory) un artefact de votre build.

Ajoutez le code suivant à votre fichier azure-pipelines.yml :

steps:

- task: DotNetCoreCLI@2
  inputs:
    command: publish
    publishWebProjects: True
    arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
    zipAfterPublish: True

- task: PublishPipelineArtifact@1
  inputs:
    targetPath: '$(Build.ArtifactStagingDirectory)' 
    artifactName: 'myWebsite'

Pour copier plus de fichiers vers le répertoire de build avant la publication, utilisez la tâche Copier des fichiers (CopyFile@2).

Remarque

L’entrée publishWebProjects de la tâche .NET Core (DotNetCoreCLI@2) est définie true par défaut et publie tous les projets web dans votre référentiel. Pour plus d’informations, consultez le référentiel GitHub azure-pipelines-tasks .

Pour plus d’informations, veuillez consulter la section Publier et télécharger des artefacts de build.

Publier sur un flux NuGet

Pour créer un package NuGet et le publier dans votre flux NuGet, ajoutez l’extrait de code suivant à votre fichier azure-pipelines.yml :

steps:
# ...
# do this near the end of your pipeline
- script: dotnet pack /p:PackageVersion=$(version)  # define the version variable elsewhere in your pipeline
- task: NuGetAuthenticate@1
  inputs:
    nuGetServiceConnections: '<NuGet service connection>'
- task: NuGetCommand@2
  inputs:
    command: push
    nuGetFeedType: external
    publishFeedCredentials: '<NuGet service connection>'
    versioningScheme: byEnvVar
    versionEnvVar: version

Remarque

La NuGetAuthenticate@1 tâche ne prend pas en charge l’authentification par clé API NuGet. Si vous utilisez une clé API NuGet, utilisez la tâche avec l’entrée NuGetCommand@2command définie push sur et l’argument --api-key . Par exemple : dotnet nuget push --api-key $(NuGetApiKey).

Pour plus d’informations sur le contrôle de version et la publication de packages NuGet, consultez Publier des packages NuGet avec Azure Pipelines.

Publiez un package NuGet sur Azure Artifacts

Vous pouvez publier vos packages NuGet sur votre flux Azure Artifacts à l’aide de la tâche NuGetCommand@2 . Pour plus d’informations, consultez Publier des packages NuGet avec Azure Pipelines.

Publier une archive de fichiers ZIP sur une application web

Pour créer une archive de fichiers ZIP prête à être publiée sur une application web, ajoutez l’extrait de code suivant à azure-pipelines.yml. Exécutez cette tâche après avoir généré votre application, près de la fin de votre pipeline dans la plupart des cas. Par exemple, exécutez cette tâche avant de déployer sur une application web Azure sur Windows.

steps:
# ...
- task: DotNetCoreCLI@2
  inputs:
    command: publish
    publishWebProjects: True
    arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
    zipAfterPublish: True

Pour publier cette archive dans une application web, consultez Déploiement d’applications web Azure.

Publiez des symboles

Vous pouvez utiliser la PublishSymbols@2 tâche pour publier des symboles sur un serveur de symboles Azure Artifacts ou un partage de fichiers. Pour plus d’informations, veuillez consulter la section Publier des symboles.

Par exemple, pour publier des symboles dans un partage de fichiers, ajoutez l’extrait de code suivant à votre fichier azure-pipelines.yml :

- task: PublishSymbols@2
  inputs:
    SymbolsFolder: '$(Build.SourcesDirectory)'
    SearchPattern: '**/bin/**/*.pdb'
    IndexSources: true
    PublishSymbols: true
    SymbolServerType: 'FileShare' 
    SymbolsPath: '\\<server>\<shareName>'

Pour utiliser l’éditeur classique, ajoutez les sources d’index et publiez des symboles à votre pipeline.

Résolution des problèmes

Si votre projet s’appuie correctement sur votre ordinateur local, mais pas dans Azure Pipelines, explorez les causes potentielles et les actions correctives suivantes.

• Les versions préliminaires du Kit de développement logiciel (SDK) .NET Core ne sont pas installées sur les agents hébergés par Microsoft, et le déploiement d’une nouvelle version du Kit de développement logiciel (SDK) sur tous les centres de données Azure Pipelines peut prendre quelques semaines. Au lieu d’attendre la fin d’un déploiement, vous pouvez utiliser la tâche Utiliser .NET Core pour installer la version du Kit de développement logiciel (SDK) .NET Core souhaitée sur les agents hébergés par Microsoft.

• Une nouvelle version du Kit de développement logiciel (SDK) .NET Core ou de Visual Studio peut interrompre la génération, par exemple si elle contient une version ou une fonctionnalité plus récente de l’outil NuGet. Vérifiez que les versions et le runtime du Kit de développement logiciel (SDK) .NET Core sur votre ordinateur de développement correspondent à l’agent de pipeline.

  Vous pouvez inclure un dotnet --version script de ligne de commande dans votre pipeline pour imprimer la version du Kit de développement logiciel (SDK) .NET Core. Utilisez le programme d’installation de l’outil .NET Core pour déployer la même version sur l’agent, ou mettez à jour vos projets et votre ordinateur de développement vers la version du pipeline du Kit de développement logiciel (SDK) .NET Core.

• Vos builds peuvent échouer par intermittence en raison de problèmes de connexion lorsque vous restaurez des packages à partir de NuGet.org. NuGet.org peut rencontrer des problèmes, ou il peut y avoir des problèmes réseau entre le centre de données Azure et NuGet.org. Vous pouvez déterminer si l’utilisation d’Azure Artifacts avec des sources en amont pour mettre en cache les packages améliore la fiabilité de vos builds.

  Les informations d’identification du pipeline sont automatiquement utilisées pour se connecter à Azure Artifacts. Ces informations d’identification sont généralement dérivées du compte de service de build de collection de projets. Pour en savoir plus sur l’utilisation d’Azure Artifacts pour mettre en cache vos paquets NuGet, veuillez consulter la section Connect to Azure Artifact feeds.

• Vous utilisez peut-être une logique dans Visual Studio qui n’est pas encodée dans votre pipeline. Azure Pipelines exécute chaque commande d’une tâche de manière séquentielle dans un nouveau processus. Examinez les journaux d’activité de la build des pipelines pour voir les commandes exactes exécutées dans la build. Pour localiser le problème, répétez les mêmes commandes dans le même ordre sur votre ordinateur de développement.

• Si vous avez une solution mixte qui inclut certains projets .NET Core et certains projets .NET Framework, utilisez la tâche NuGet pour restaurer des packages spécifiés dans les fichiers packages.config . Ajoutez la tâche MSBuild ou Visual Studio Build pour générer les projets .NET Framework.

Contenu connexe

• Artefacts Azure
• Tâches de génération et de mise en production
• Outils CLI .NET Core
• Tests unitaires dans les projets .NET Core