Jérémy Jeanson's blog
chasseur de bugs depuis .net 1.0

Depuis le début, l'usage de Microsoft Testing Platform n'est pas de tout repos. Pour compliquer la chose, il n'existe aucun Template de build.

Mais en se penchant sur les différentes documentations, on finit par trouver une solution.

Je vous propose aujourd'hui une procédure de mon cru que j’utilise avec succès depuis deux mois.

Dans un premier temps, nous devons créer un fichier globa.json à la racine du repository.

{
  "test": {
    "runner": "Microsoft.Testing.Platform"
  }
}

Ensuite, il faut résoudre les problèmes suivants :

• DotNetCoreCLI@2 test, ne peut pas être utilisé avec la propriété projects.
• DotNetCoreCLI@2 test, ajoute des arguments propres à VSTest quand on laisse la publication automatique active.
• DotNetCoreCLI@2 test, n'applique pas le fichier global.json s'il n'est pas à la racine du repository.

Ma solution consiste donc en l'enchaînement de taches qui suit :

- task: DotNetCoreCLI@2
    displayName: 'Compilation'
    inputs:
      command: build
      projects: $(solution)
      arguments: '--configuration $(buildConfiguration)'

  - task: DotNetCoreCLI@2
    displayName: 'Tests unitaires'
    inputs:
      command: test
      publishTestResults: false
      arguments: '--solution $(solution) --no-restore --configuration $(buildConfiguration) --report-trx --results-directory $(Agent.TempDirectory) --coverage --coverage-output-format cobertura --coverage-output coverage.cobertura.xml'      
      # si le global.json est dans un dossier "Sources"
      # workingDirectory: '$(Build.SourcesDirectory)\Sources\'

  - task: PublishTestResults@2
    displayName: "Publication des resultats des tests unitaires"
    condition: always()
    inputs:
      testResultsFormat: VSTest
      searchFolder: $(Agent.TempDirectory)
      testResultsFiles: "**/*.trx"

  - task: reportgenerator@5
    displayName: 'Génération du rapport de couverture de code'
    inputs:
      reports: '$(Agent.TempDirectory)/**/coverage.cobertura.xml'      
      targetdir: 'coveragereport'
      publishCodeCoverageResults: true  

Note: Aucune IA n’a été maltraitée pour obtenir cette solution.

Voici une situation qui peut être embrassante si vous devez utiliser un fichier global.json avec Azure Pipeline : la tâche DotNetCoreCLI@2 n'utilise pas votre fichier global.json.

Ce problème se produit si le fichier global.json ne se trouve pas à la racine du repository.

Celui-ci a déjà été reporté sur GitHub [BUG]: DotNetCoreCLI@2 global.json lookup is hardcoded to repository root · Issue #21523 · microsoft/azure-pipelines-tasks.

Malheureusement, cette issue date de décembre, et n'a toujours pas été résolue.

Il existe cependant une solution de contournement qui n'est pas documentée. Elle consiste à utiliser la propriété workingDirectory de la tâche DotNetCoreCLI@2. En affectant à celle-ci le dossier dans lequel se trouve le fichier global.json, on résout le problème.

Exemple :

- task: DotNetCoreCLI@2
  displayName: 'Compilation'
  inputs:
    command: build
    projects: $(solution)
    workingDirectory: '$(Build.SourcesDirectory)\Sources\'

Je vous propose aujourd'hui de présenter une situation qui m'a fait perdre un certain temps ;).

Je dispose d'un projet Blazor qui utilise l'authentification Windows avec succès depuis quelques années. Lors d'une récente évolution, j'ai été amené à lui ajouter une seconde forme d'authentification.

Tout va bien jusqu'au moment où l'authentification Windows se met à ne plus fonctionner. Que le navigateur reconnaisse le site comme étant un site de confiance ou non. L'utilisateur ne reçoit plus de demande d'authentifications.

Le problème est lié à l'appel de la méthode .AllowAnonymous() après le maping des composants  Blazor. L'utilisateur peut être anonyme. La demande de challenge ne se fait plus non plus.

Exemple de code :

app.MapRazorComponents<App>()
  .AddInteractiveServerRenderMode()
  .AllowAnonymous();

Pour résoudre le problème, il faut donc mettre en place une logique qui n'utilise la méthode AllowAnonymous() qu'à partir du moment où l'authentification Windows n'est pas requise.

Vous souhaitez utiliser Visual Studio 2026, et ses builds tools dans votre CI / CD avec Azure Devops, mais cela ne fonctionne pas ?

Pas de panique, ce scénario est parfaitement supporté. Il suffit de mettre à jour vos agents de build avec une version 4.266.2 ou supérieure .

Petit lien ver la Release v4.266.2 · microsoft/azure-pipelines-agent

Features

• Add Visual Studio 2026 (version 18.0) support to capability detection (#5406)

Pour débuter cette nouvelle année, je souhaite vous parler d’un warning que j’affectionne tout particulièrement.

Avant d’aller plus loin, non je ne suis pas masochiste. J’e n’aime pas particulièrement les warnings, mais j’aime les résoudre. Chaque warning résolu permet d’éviter un futur problème.

Avec .net 10, un nouveau warning a fait son apparition. Le warning référencé NU1510. Celui-ci met en avant les projets qui ont des références inutiles. Il met aussi en avant la référence inutile.

Quand on aime les projets propres, c’est un must.

Petite subtilité qui me fait tout particulièrement apprécier ce warning : celui-ci met aussi en avant les dépenses transitives qui sont référencées manuellement (dans le petit monde .net on perle souvent de dépendances indirectes au lieu de dépenses transitives). Ce type de référence se produit souvent quand on souhaite forcer une montée de version suite à la découverte d’une faille sur une dépendance transitive. Quand la dépendance directe est mise à jour, et qu’elle cible la dernière version de la dépendance transitive, le warning apparait. J’adore !