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

Certaines personnes semblent avoir été un peu surprises par l'arrivée de l'agent Azure pipeline en version 4. Même si une très grosse partie des informations concernant les évolutions de cet agent sont consulta via GitHub, la documentation reste sur Microsoft Learn.

On peut entre autres, y trouver une FAQ très complète de la version 4. Celle-ci est disponible via ce lien : Agent software version 4 - Azure Pipelines | Microsoft Learn

Actuellement, Azure DevOps Server est livré avec une version 3 de l'agent Azure Pipelines. Il est cependant tout à fait possible d'installer, et d'utiliser la version 4.

Celle-ci est parfaitement compatible avec Azure DevOps Server 2022 update 2.

Testé, et approuvé avec le patch 2 de novembre 2024.

En cas de besoin, voici un article expliquant la méthode permettant de forcer à la mise à jour des agents.

Si vous suivez le GitHub de l'agent Azure Pipelines vous avez peut-être constaté que la dernière release est taguée v4.251.

Le changement de numérotation peut surprendre, mais il s'explique par une évolution majeure. La version 4 utilise .net 8.

La première version 4 a été distribuée en octobre / novembre dernier. Cependant, elle n'a pas été taguée comme étant la dernière version stable. L'utilisation de .net 8 rend l'agent incompatible avec certains OS, car ils n'ont pas été mis à jour pour supporter .net 8 (distributions Linux principalement, plus quelques anciennes versions de Mac OS, et Windows dépréciés). Le détail est disponible ici.

La mise en avant de la version 4 fait donc suite à la fin du support de .net 6.

Microsoft ne force pas le passage à la version 4. Une version taguée v3.251 utilisant .net 6 reste disponible. Vous pouvez donc continuer à utiliser cet agent, si vos OS ne sont pas supportés.

Attention

Même si la version 3 reçoit des correctifs, elle ne pourra pas pallier un éventuel problème lié à .net 6. Il est donc fortement conseillé de passer à la version 4 dès que possible.

Il arrive que l'on ait à partager des fichiers AssemblyInfo entre des projets au format SDK, et aussi des projets à l'ancien format.

Dans le cadre d'un projet au format SDK, cette approche n'est pas possible sans une petite adaptation. Les numéros de versions, ainsi que les divers éléments d'informations de l'assembly étant produits à partir du XML du projet (ou d'un fichier directory.build.props).

Si l'on souhaite utiliser un fichier commun AssemblyInfo .cs, ou AssemblyInfo.vb, il faut donc commencer par désactiver la génération de ces informations.

Heureusement, il existe une solution simple pour cela. Il suffit d'ajouter les nœuds suivants à son projet XML :

<GenerateAssemblyVersionAttribute>false</GenerateAssemblyVersionAttribute>
<GenerateAssemblyFileVersionAttribute>false</GenerateAssemblyFileVersionAttribute>
<GenerateAssemblyInformationalVersionAttribute>false</GenerateAssemblyInformationalVersionAttribute>

Documentation : Set assembly attributes in project files - .NET | Microsoft Learn

Lors de mon déménagement, j'ai eu une petite mésaventure qui a conduit à la perte de deux SSD en miroir. Ceux-ci contenant les VM de l'un de mes Hyper-V, la remise en service de celui-ci a été un peu laborieuse.

Malgré la reconstruction d'un volume vierge pour le stockage de mes VM, Hyper-V continuait à m'afficher les VM perdues. La console ne permettait pas de les supprimer.

Il m'a donc fallu un peu ruser, et comprendre d'où Hyper-V tirait cette liste de VMs fantômes. C'est alors que j'ai découvert l'existence du dossier "Virtual Machines Cache" (merci Microsoft Learn)

Ma solution a donc consisté en la suppression de ce dossier.

Pour cela, il faut commencer par couper le service de gestion d'Hyper-V :

net stop vmms

The Hyper-V Virtual Machine Management service is stopping.
The Hyper-V Virtual Machine Management service was stopped successfully.

On peut ensuite supprimer le dossier contenant le cache (via une invite powershell, la commande a un petit aire de Linux ;) ):

rm -r 'C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines Cache\'

Pour finir, on relance le service de gestion d'Hyper-V

net start vmms

The Hyper-V Virtual Machine Management service is starting.
The Hyper-V Virtual Machine Management service was started successfully.

Le dossier est alors recréé. Les VMs fantôme ont disparues. On peut à nouveau jouer normalement avec Hyper-V.