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

Migrer une ferme Azure DevOps d'un domaine à l'autre, demande un peu de doigté. Surtout pour ce qui concerne la gestion des utilisateurs.

Heureusement, la CLI permet de déplacer les utilisateurs  d'un domaine à l'autre. Cela est plutôt bien expliqué dans la documentation que l'on peut consulter ici.

Mais il arrive que cela ne fonctionne pas pour quelques utilisateurs (petites différences dans le login, nom changé… etc…).

Pour cela, on peut compter sur la commande qui suit :

# Mapping de l'utilisateur
.\TFSConfig Identities /change /fromdomain:AncienDomaine/todomain:NouveauDomaine /account:AncienLogin /toaccount:NouveauLogin

Malheureusement, dans le cas d'une migration d'un domaine vers un workgroup, cela ne fonctionne pas. On lance les diverses commandes, mais les utilisateurs ne récupérèrent pas leurs droits, espaces de travail, requêtes, tableaux de bord, branches, etc.

Fort heureusement, il suffit de faire un petit tour dans la base de données de configuration pour corriger cela (par défaut, il s'agit de la base TFS_Config)

Dans un premier temps, il faut identifier les lignes relatives aux différentes identités de notre utilisateur. Exemple :

SELECT *
FROM tbl_Identity
WHERE AccountName LIKE '%NouveauLogin%'

En même temps, on peut utiliser powershell pour recouper ces informations avec le nouveau SID de l'utilisateur.

# Vérification du SID Windows de l'utilisateur local
Get-LocalUser -Name "NouveauLogin" | Select Name, SID

Avec ces informations, vous devriez pouvoir identifier :

• L'ancien ID
• L'ancien SID
• Le nouvel ID
• Le nouveau SID

Ensuite, pour intervertir les identités, il suffit d'échanger les ID.

Personnellement, j'opte pour une solution simple en trois étapes:

1. Affecter un faux ID à la ligne contenant le nouveau SID.
2. Affecter le nouvel ID à la ligne contenant l'ancien SID.
3. Affecter l'ancien ID à la ligne contenant le nouveau SID.

Exemple :

UPDATE tbl_Identity
SET [id]='F5331C74-6F8F-40C2-8F8E-000000000000'
WHERE [sId]='S-1-5-12-383200802-4186732323-4104849335-7817'
 
UPDATE tbl_Identity
SET [id]='AF9C2B4C-E4A4-43A9-B5E4-E9337DA9D900'
WHERE [sId]='S-1-5-33-2491080940-717456908-2923986041-1018'
 
UPDATE tbl_Identity
SET [id]='F5331C74-6F8F-40C2-8F8E-F3F943EF99A5'
WHERE [sId]='S-1-5-12-383200802-4186732323-4104849335-7817'

Aujourd'hui, le support des Builds Tools 2026 avec Azure Devops est un peu déroutant. Des projets .net 10 tournant sans problèmes, et certains projets .net Framework remontent des erreurs datant du passage de .net Framework 3.5 à 4.0.

Contrairement à leurs habitudes, les équipes de Microsoft ne semblent pas très synchronisées :

• Les agents de builds détectent bien les fonctionnalités de VS 2026, et les builds Tools 2026.
• Les taches ne détectent pas toutes les fonctionnalités de VS 2026, et les builds Tools 2026.

On se retrouve donc dans une situation où l'agent dit : "j'ai les bons outils, tu peux t'exécuter ici",  et les tâches "je ne trouve pas les outils dont j'ai besoin, je vais faire avec ce que je trouve".

La solution simple, et sans modification des pipelines

Sur un serveur de build disposant des Builds Tools 2026, et 2022, on ne se rend compte de rien. Une solution temporaire peut donc consister à utiliser les deux versions de ses outils. La version 2026 étant indispensable pour utiliser .net 10.

La solution temporaire, avec modification des pipelines

Une solution ne s'appuyant que sur les Build Tools 2026 consiste à spécifier les chemins vers les binaires (ex: msbuildLocation pour MSBuild@1, et vstestLocation pour VSTest@3).

Je ne suis pas du tout fan de cette solution. Quand on est habitué à utiliser des produits de Microsoft, on aime que tout fonctionne sans avoir à tout retoucher à chaque montée de version de l'outillage.

Remarque : Le fait de mettre des chemins vers des binaires, en dure dans une build, n'est pas une bonne pratique. Il faut cependant noter que cette approche est utilisée par nombre de solutions concurrentes comme GitLab, ou Jenkins...

Ce qui est une solution temporaire "peu optimale" pour DevOps, est une solution permanente pour d'autres.

Aujourd'hui, je vous propose d'aborder un sujet très peu documenté. Je dispose d'un serveur Azure DevOps qui ne fait pas partie d'un domaine (ne cherchez pas la raison, c'est une contrainte avec laquelle je dois faire).

Par défaut les agents ne sont pas en mesure de s'enregistrer auprès du serveur.

L'habituelle authentification Windows par défaut via NTLM ou Kerberos ne passe pas. Pour résoudre le problème, il faut modifier la configuration du site IIS hébergeant DevOps afin d'utiliser Negociate. La procédure est documentée ici : Azure Devops Docs · GitHub.

Il faut ensuite adapter les arguments passés au script config.md comme ceci (en adaptant les identifiants, le nom de l'agent, et l'URL de la collection DevOps) :

.\config.cmd  --auth negotiate --userName "login" --password "password" --pool Default --agent build1 --acceptTeeEula --runasservice --work '_work' --url 'http://serveur.devops/collection'

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