Comment forcer l'usage des Build Tools 2026 avec Azure Pipeline ?
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.