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

Azure Pipelines | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 | TFS 2017

Utilisez un pipeline pour générer et tester automatiquement vos projets .NET Core. Découvrez comment :

Notes

pour obtenir de l’aide sur les projets de .NET Framework, consultez générer des applications ASP.NET avec .NET Framework.

Notes

dans Microsoft Team Foundation Server (TFS) 2018 et versions antérieures, les pipelines de build et de mise en version sont appelés définitions, les exécutions sont appelées builds, les connexions de service sont appelées points de terminaison de service, les étapes sont appelées environnements et les tâches sont appelées phases.

Notes

Ce guide s’applique à TFS version 2017,3 et versions ultérieures.

Créer votre premier pipeline

Vous débutez en Azure Pipelines ? Si c’est le cas, nous vous recommandons d’essayer cette section avant de passer à d’autres sections.

Obtenir le code

Embrancher ce référentiel dans GitHub :

importez ce référentiel dans votre référentiel Git dans Azure DevOps Server 2019 :

Importez ce référentiel dans votre référentiel git dans TFS :

https://github.com/MicrosoftDocs/pipelines-dotnet-core

Connectez-vous à Azure Pipelines

Connectez-vous à Azure pipelines. une fois que vous êtes connecté, votre navigateur accède à https://dev.azure.com/my-organization-name et affiche votre tableau de bord Azure DevOps.

Dans votre organisation sélectionnée, créez un projet. Si vous n’avez aucun projet dans votre organisation, vous voyez un écran créer un projet pour commencer. dans le cas contraire, sélectionnez le bouton créer un Project dans l’angle supérieur droit du tableau de bord.

Créer le pipeline

  1. Connectez-vous à votre organisation Azure DevOps et accédez à votre projet.

  2. accédez à Pipelines, puis sélectionnez nouveau pipeline.

  3. Suivez les étapes de l’Assistant en sélectionnant d’abord GitHub comme emplacement du code source.

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

  5. Lorsque la liste des référentiels s’affiche, sélectionnez votre référentiel.

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

Lorsque l’onglet configurer s’affiche, sélectionnez ASP.net Core.

  1. Lorsque votre nouveau pipeline apparaît, jetez un coup d’œil à YAML pour voir ce qu’il fait. Lorsque vous êtes prêt, sélectionnez enregistrer et exécuter.

    Bouton enregistrer et exécuter dans un nouveau pipeline YAML

  2. Vous êtes invité à valider un nouveau fichier Azure-pipelines. yml dans votre référentiel. Une fois que vous êtes satisfait du message, sélectionnez enregistrer et exécuter à nouveau.

    Si vous souhaitez regarder votre pipeline en action, sélectionnez la tâche de Build.

    vous venez de créer et d’exécuter un pipeline que nous avons créé automatiquement pour vous, car votre code semblait être une bonne correspondance pour le modèle de ASP.NET Core .

    Vous disposez maintenant d’un pipeline YAML fonctionnel ( azure-pipelines.yml ) dans votre référentiel qui est prêt à être personnalisé.

  3. lorsque vous êtes prêt à apporter des modifications à votre pipeline, sélectionnez-le dans la page Pipelines , puis modifiez le azure-pipelines.yml fichier.

  4. Consultez les sections ci-dessous pour découvrir quelques-unes des méthodes les plus courantes pour personnaliser votre pipeline.

YAML

  1. Ajoutez un azure-pipelines.yml fichier à votre référentiel. Personnalisez cet extrait de code pour votre Build.
trigger:
- master

pool: Default

variables:
  buildConfiguration: 'Release'

# do this before all your .NET Core tasks
steps:
- task: DotNetCoreInstaller@2
  inputs:
    version: '2.2.402' # replace this value with the version that you need for your project
- script: dotnet build --configuration $(buildConfiguration)
  displayName: 'dotnet build $(buildConfiguration)'
  1. Créez un pipeline (si vous ne savez pas comment procéder, consultez créer votre premier pipeline) et pour le modèle, sélectionnez YAML.

  2. Définissez le pool d’agents et le chemin d’accès du fichier YAML pour votre pipeline.

  3. Enregistrer le pipeline et mettre en file d’attente une build. Quand le message #nnnnnnnn. n a été mis en file d’attente s’affiche, sélectionnez le lien numéro pour voir votre pipeline en action.

  4. Lorsque vous êtes prêt à apporter des modifications à votre pipeline, Modifiez -le.

  5. Consultez les sections ci-dessous pour découvrir quelques-unes des méthodes les plus courantes pour personnaliser votre pipeline.

Classique

  1. Créer un pipeline (si vous ne savez pas comment procéder, consultez créer votre premier pipeline). Sélectionnez pipeline vide pour le modèle.

  2. Dans le catalogue des tâches, recherchez et ajoutez la tâche .net Core . Cette tâche est exécutée dotnet build pour générer le code dans l’exemple de référentiel.

  3. Enregistrer le pipeline et mettre en file d’attente une build. Quand le message #nnnnnnnn. n a été mis en file d’attente s’affiche, sélectionnez le lien numéro pour voir votre pipeline en action.

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

  4. Lorsque vous êtes prêt à apporter des modifications à votre pipeline, Modifiez -le.

  5. Consultez les sections ci-dessous pour découvrir quelques-unes des méthodes les plus courantes pour personnaliser votre pipeline.

Environnement de génération

utilisez Azure Pipelines pour générer vos projets .net Core sur Windows, Linux ou macOS, sans avoir à configurer les infrastructures de votre choix. les agents hébergés par Microsoft dans Azure Pipelines incluent plusieurs versions publiées des kits de développement logiciel (sdk) .net Core préinstallés.

Ubuntu 18,04 est défini ici dans le fichier YAML.

pool:
  vmImage: 'ubuntu-18.04' # examples of other options: 'macOS-10.15', 'windows-2019'

Pour obtenir des exemples supplémentaires, consultez agents hébergés par Microsoft pour obtenir la liste complète des images et des Pools .

Les agents hébergés par Microsoft n’incluent pas certaines des versions antérieures du kit SDK .NET Core. Ils n’incluent pas non plus généralement les versions préliminaires. Si vous avez besoin de ces types de kits de développement logiciel (SDK) sur des agents hébergés par Microsoft, ajoutez la UseDotNet@2 tâche à votre fichier YAML.

Pour installer la version préliminaire du kit de développement logiciel (SDK) 5.0. x afin de générer et 3.0. x pour exécuter des tests qui ciblent .NET Core 3.0. x, ajoutez cet extrait de code :

steps:
- task: UseDotNet@2
  inputs:
    version: '5.0.x'
    includePreviewVersions: true # Required for preview versions

- task: UseDotNet@2
  inputs:
    version: '3.0.x'
    packageType: runtime

Windows agents incluent déjà un runtime .net Core. Pour installer un nouveau kit de développement logiciel (SDK), définissez performMultiLevelLookup sur true dans cet extrait de code :

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

Conseil

Vous pouvez également configurer un agent auto-hébergé et économiser le coût d’exécution du programme d’installation de l’outil. Voir Linux, MacOSou Windows. Vous pouvez également utiliser des agents auto-hébergés pour gagner du temps, si vous disposez d’un référentiel volumineux ou si vous exécutez des builds incrémentielles. un agent auto-hébergé peut également vous aider à utiliser la version préliminaire ou les kits de développement privés qui ne sont pas officiellement pris en charge par Azure DevOps ou qui ne sont disponibles que dans vos environnements locaux ou d’entreprise.

vous pouvez générer vos projets .net Core à l’aide de l’kit SDK .NET Core et du runtime sur Windows, Linux ou macOS. Vos builds s’exécutent sur un agent auto-hébergé. Assurez-vous que la version requise du kit SDK .NET Core et du runtime est installée sur l’agent.

Restaurer les dépendances

NuGet est un moyen courant de dépendre du code que vous ne générez pas. vous pouvez télécharger NuGet packages et les outils spécifiques au projet qui sont spécifiés dans le fichier projet en exécutant la dotnet restore commande via la tâche .net Core ou directement dans un script de votre pipeline.

vous pouvez télécharger des packages NuGet à partir de Azure Artifacts, NuGet. org ou un autre référentiel de NuGet externe ou interne. la tâche .net Core est particulièrement utile pour restaurer des packages à partir de flux de NuGet authentifiés.

Ce pipeline utilise un flux d’artefact pour dotnet restore dans la tâche CLI .net Core.

trigger:
- master

pool:
  vmImage: 'windows-latest'

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

vous pouvez télécharger des packages NuGet à partir de NuGet. org.

dotnet restore utilise en interne une version de NuGet.exe qui est empaquetée avec l’kit SDK .net core. dotnet restore peut uniquement restaurer les packages spécifiés dans les fichiers projet .NET Core .csproj . si vous avez également un projet Microsoft .NET Framework dans votre solution ou si vous utilisez package.json pour spécifier vos dépendances, vous devez également utiliser la tâche NuGet pour restaurer ces dépendances.

Dans kit SDK .NET Core version 2,0 et versions ultérieures, les packages sont restaurés automatiquement lors de l’exécution d’autres commandes telles que dotnet build .

Dans kit SDK .NET Core version 2,0 et versions ultérieures, les packages sont restaurés automatiquement lors de l’exécution d’autres commandes telles que dotnet build . Toutefois, vous devrez peut-être encore utiliser la tâche .net Core pour restaurer des packages si vous utilisez un flux authentifié.

si vos builds échouent occasionnellement lors de la restauration de packages à partir de NuGet. org en raison de problèmes de connexion, vous pouvez utiliser Azure Artifacts avec les sources amont et mettre en cache les packages. Les informations d’identification du pipeline sont utilisées automatiquement lors de la connexion à Azure Artifacts. ces informations d’identification sont généralement dérivées du compte de Service de Build de la Collection Project .

si vous souhaitez spécifier un référentiel NuGet, placez les url dans un NuGet.config fichier de votre référentiel. si votre flux est authentifié, gérez ses informations d’identification en créant une connexion de service NuGet sous l’onglet Services sous Project Paramètres.

Si vous utilisez des agents hébergés par Microsoft, vous recevez un nouvel ordinateur chaque fois que vous exécutez une build, ce qui revient à restaurer les packages à chaque fois. Cette restauration peut prendre beaucoup de temps. pour atténuer ce problème, vous pouvez utiliser Azure Artifacts ou un agent auto-hébergé, auquel cas vous tirez parti de l’utilisation du cache de package.

Pour restaurer des packages à partir d’un flux personnalisé externe, utilisez la tâche .net Core :

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

pour plus d’informations sur les connexions de service NuGet, consultez publier sur des flux NuGet.

  1. Sélectionnez tâches dans le pipeline. Sélectionnez le travail qui exécute vos tâches de génération. Sélectionnez ensuite + pour ajouter une nouvelle tâche à ce travail.

  2. Dans le catalogue des tâches, recherchez et ajoutez la tâche .net Core .

  3. Sélectionnez la tâche et, pour commande, sélectionnez restaurer.

  4. Spécifiez les autres options dont vous avez besoin pour cette tâche. Enregistrez ensuite la Build.

Notes

assurez-vous que le flux personnalisé est spécifié dans votre NuGet.config fichier et que les informations d’identification sont spécifiées dans la connexion au service NuGet.

Générer votre projet

Pour générer votre projet .NET Core, vous devez exécuter la dotnet build commande dans votre pipeline ou à l’aide de la tâche .net core.

Pour générer votre projet à l’aide de la tâche .NET Core, ajoutez l’extrait de code suivant à votre azure-pipelines.yml fichier :

steps:
- task: DotNetCoreCLI@2
  displayName: Build
  inputs:
    command: build
    projects: '**/*.csproj'
    arguments: '--configuration $(buildConfiguration)' # Update this to match your need

Vous pouvez exécuter n’importe quelle commande dotnet personnalisée dans votre pipeline. L’exemple suivant montre comment installer et utiliser un outil .NET global, dotnetsay:

steps:
- task: DotNetCoreCLI@2
  displayName: 'Install dotnetsay'
  inputs:
    command: custom
    custom: tool
    arguments: 'install -g dotnetsay'

Build

  1. Sélectionnez tâches dans le pipeline. Sélectionnez le travail qui exécute vos tâches de génération. Sélectionnez ensuite + pour ajouter une nouvelle tâche à ce travail.

  2. Dans le catalogue des tâches, recherchez et ajoutez la tâche .net Core .

  3. Sélectionnez la tâche et, pour commande, sélectionnez générer ou publier.

  4. Spécifiez les autres options dont vous avez besoin pour cette tâche. Enregistrez ensuite la Build.

Installer un outil

pour installer un outil global .net Core comme dotnetsay dans votre build s’exécutant sur Windows, procédez comme suit :

  1. Ajoutez la tâche .net Core et définissez les propriétés suivantes :

    • Commande: personnalisée.
      • Chemin d’accès aux projets: laissez vide.
    • Commande personnalisée: outil.
    • Arguments: install -g dotnetsay .
  2. Ajoutez une tâche de ligne de commande et définissez les propriétés suivantes :

    • Script : dotnetsay .

Exécutez vos tests.

Si vous avez des projets de test dans votre référentiel, utilisez la tâche .net Core pour exécuter des tests unitaires à l’aide d’infrastructures de test telles que MSTest, xUnit et nunit. Pour cette fonctionnalité, le projet de test doit référencer Microsoft. net. test. SDK version 15.8.0 ou ultérieure. Les résultats des tests sont automatiquement publiés dans le service. Ces résultats sont ensuite mis à votre disposition dans le résumé de la build et peuvent être utilisés pour le dépannage des tests ayant échoué et l’analyse du minutage des tests.

Ajoutez l’extrait de code suivant à votre azure-pipelines.yml fichier :

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

Une alternative consiste à exécuter la dotnet test commande avec un enregistreur d’événements spécifique, puis à utiliser la tâche publier le résultats des tests :

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

Utilisez la tâche .net Core avec le jeu de commandes pour Tester. Le chemin d’accès aux projets doit faire référence aux projets de test de votre solution.

Collecter la couverture du code

si vous créez sur la plateforme Windows, les métriques de couverture du code peuvent être collectées à l’aide du collecteur de données de couverture intégré. Pour cette fonctionnalité, le projet de test doit référencer Microsoft. net. test. SDK version 15.8.0 ou ultérieure. Si vous utilisez la tâche .net Core pour exécuter des tests, les données de couverture sont automatiquement publiées sur le serveur. Le fichier . coverage peut être téléchargé à partir du résumé de la build pour consultation dans Visual Studio.

Ajoutez l’extrait de code suivant à votre azure-pipelines.yml fichier :

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

Si vous choisissez d’exécuter la dotnet test commande, spécifiez les options de couverture et de journalisation des résultats des tests. Utilisez ensuite la tâche publier le résultats des tests :

steps:
# ...
# do this after your tests have run
- script: dotnet test <test-project> --logger trx --collect "Code coverage"
- task: PublishTestResults@2
  inputs:
    testRunner: VSTest
    testResultsFiles: '**/*.trx'
  1. Ajoutez la tâche .NET Core à votre travail de génération et définissez les propriétés suivantes :

    • Commande: test.
    • Chemin d’accès aux projets: doit faire référence aux projets de test de votre solution.
    • Arguments: --configuration $(BuildConfiguration) --collect "Code coverage" .
  2. Assurez-vous que l’option publier les résultats des tests reste sélectionnée.

Collecter les métriques de couverture du code avec coverlet

Si vous créez sur Linux ou macOS, vous pouvez utiliser coverlet ou un outil similaire pour collecter les métriques de couverture du code.

Les résultats de couverture du code peuvent être publiés sur le serveur à l’aide de la tâche publier les résultats de la couverture du code . Pour utiliser cette fonctionnalité, l’outil de couverture doit être configuré 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 :

  • ajoutez une référence au coverlet.msbuild package NuGet dans vos projets de test pour les projets .net inférieurs à .net 5. pour .net 5, ajoutez une référence au coverlet.collector package NuGet.
  • Ajoutez cet extrait de code à votre azure-pipelines.yml fichier :
- task: UseDotNet@2
  inputs:
    version: '5.0.x'
    includePreviewVersions: true # Required for preview versions
  
- task: DotNetCoreCLI@2
  displayName: 'dotnet build'
  inputs:
    command: 'build'
    configuration: $(buildConfiguration)
  
- 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: 'MyTestLibrary' # update with your test project directory
  
- task: PublishCodeCoverageResults@1
  displayName: 'Publish code coverage report'
  inputs:
    codeCoverageTool: 'Cobertura'
    summaryFileLocation: '$(Agent.TempDirectory)/**/coverage.cobertura.xml'

Empaqueter et remettre votre code

une fois que vous avez créé et testé votre application, vous pouvez télécharger la sortie de la génération vers Azure Pipelines ou TFS, créer et publier un package NuGet, ou empaqueter la sortie de la génération dans un fichier .zip à déployer dans une application web.

Publier les artefacts sur Azure Pipelines

Pour publier la sortie de votre Build.net,

  • Exécutez dotnet publish --output $(Build.ArtifactStagingDirectory) sur l’interface CLI ou ajoutez la DotNetCoreCLI@2 tâche à l’aide de la commande publier.
  • Publiez l’artefact à l’aide de la tâche de publication d’artefact.

Ajoutez l’extrait de code suivant à votre azure-pipelines.yml fichier :

steps:

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

# this code takes all the files in $(Build.ArtifactStagingDirectory) and uploads them as an artifact of your build.
- task: PublishPipelineArtifact@1
  inputs:
    targetPath: '$(Build.ArtifactStagingDirectory)' 
    artifactName: 'myWebsiteName'

Notes

La dotNetCoreCLI@2 tâche a une publishWebProjects entrée qui a la valeur true par défaut. Par défaut, tous les projets Web de votre référentiel sont publiés. Vous trouverez de l’aide et des informations supplémentaires dans la tâche Open source sur GitHub.

Pour copier d’autres fichiers dans le répertoire de build avant la publication, utilisez l' utilitaire : copier les fichiers.

publier sur un flux NuGet

pour créer et publier un package NuGet, ajoutez l’extrait de code suivant :

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

pour plus d’informations sur le contrôle de version et la publication de packages NuGet, consultez publier sur des flux NuGet.

Déployer une application web

Pour créer une archive de fichiers .zip qui est prête pour la publication sur une application Web, ajoutez l’extrait de code suivant :

steps:
# ...
# do this after you've built your app, near the end of your pipeline in most cases
# for example, you do this before you deploy to an Azure web app on Windows
- 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’Azure Web Apps.

Publier les artefacts sur Azure Pipelines

utilisez la tâche publier le Artifacts pour publier la sortie de votre build sur Azure Pipelines ou TFS.

publier sur un flux NuGet

si vous souhaitez publier votre code sur un flux NuGet, procédez comme suit :

  1. Utilisez une tâche .NET Core avec la commande Set à Packer.

  2. publiez votre package sur un flux NuGet.

Déployer une application web

  1. Utilisez une tâche .NET Core avec le jeu de commandes à publier.

  2. Assurez-vous d’avoir sélectionné l’option de création d’une archive de fichiers .zip.

  3. Pour publier cette archive dans une application Web, consultez déploiement d’Azure Web Apps.

Créer une image et la transmettre au registre de conteneurs

Pour votre application, vous pouvez également générer une image et la transmettre à un registre de conteneurs.

Résolution des problèmes

si vous êtes en mesure de générer votre projet sur votre ordinateur de développement, mais que vous avez des difficultés à le créer sur Azure Pipelines ou TFS, explorez les causes potentielles et actions correctives suivantes :

  • Nous n’installons pas les versions préliminaires du kit SDK .NET Core sur les agents hébergés par Microsoft. après la publication d’une nouvelle version de la kit SDK .NET Core, il peut falloir quelques semaines pour que nous puissions la déployer dans tous les centres de données sur lesquels Azure Pipelines s’exécutent. Vous n’avez pas besoin d’attendre que nous terminions ce déploiement. Vous pouvez utiliser le programme d’installation de l’outil .net Core, comme expliqué dans cette aide, pour installer la version souhaitée du kit SDK .net Core sur les agents hébergés par Microsoft.
  • Vérifiez que les versions du kit SDK .NET Core et du Runtime sur votre ordinateur de développement correspondent à celles de l’agent. Vous pouvez inclure un script de ligne de commande dotnet --version dans votre pipeline pour imprimer la version du kit SDK .net core. Utilisez le programme d’installation de l' outil .net Core, comme expliqué dans cette aide, pour déployer la même version sur l’agent, ou mettez à jour vos projets et votre ordinateur de développement vers la version la plus récente du kit SDK .net core.

  • vous utilisez peut-être une logique dans l’IDE Visual Studio qui n’est pas encodé dans votre pipeline. Azure Pipelines ou TFS exécute chacune des commandes que vous spécifiez dans les tâches une après l’autre dans un nouveau processus. examinez les journaux de la Azure Pipelines ou de la build TFS pour voir les commandes exactes exécutées dans le cadre de la génération. Répétez les mêmes commandes dans le même ordre sur votre ordinateur de développement pour localiser le problème.

  • si vous disposez d’une solution mixte incluant certains projets .net Core et certains projets .NET Framework, vous devez également utiliser la tâche NuGet pour restaurer les packages spécifiés dans les packages.config fichiers. de même, vous devez ajouter MSBuild ou Visual Studio des tâches de génération pour générer les projets .NET Framework.

  • si vos builds échouent par intermittence pendant la restauration des packages, NuGet. org rencontre des problèmes ou il existe des problèmes réseau entre le centre de donnes Azure et NuGet. org. celles-ci ne sont pas sous notre contrôle, et vous devrez peut-être explorer l’utilisation de Azure Artifacts avec NuGet. org en tant que source amont améliore la fiabilité de vos builds.

  • parfois, lorsque nous déployons une mise à jour des images hébergées avec une nouvelle version de la kit SDK .NET Core ou Visual Studio, un événement peut endommager votre build. cela peut se produire, par exemple, si une version ou une fonctionnalité plus récente de l’outil NuGet est fournie avec le kit de développement logiciel (SDK). Pour isoler ces problèmes, utilisez la tâche du programme d’installation de l' outil .net Core pour spécifier la version du kit SDK .net Core utilisé dans votre Build.

Questions fréquentes (FAQ)

où puis-je en savoir plus sur Azure Artifacts et le service Package Management TFS ?

Package Management dans Azure Artifacts et TFS

Où puis-je en savoir plus sur les commandes .NET Core ?

Outils CLI .NET Core

Où puis-je en savoir plus sur l’exécution de tests dans ma solution ?

Tests unitaires dans les projets .NET Core

Où puis-je en savoir plus sur les tâches ?

Tâches de génération et de mise en production