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

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.

Après deux mois sans articles, il est temps que je m'explique.

En cette fin d'année, ma vie personnelle a été un peu chamboulée. Ma petite famille et moi avons déménagé. Cela m'a beaucoup occupé, et je pense que ce n'est pas fini.

J'ai pu continuer à participer aux communautés .net, mais je ne pouvais pas faire plus. J'en suis désolé. Je vous présente toutes mes excuses.

Je suis donc de retour avec beaucoup d'idées, de temps à rattraper, et d'articles à mettre au propre ;)

.net, accessibilité, et DevOps à gogo !

Suite à la publication de .net 9, j'ai mis à jour mon extension BenchmarkDotNet pour Visual Studio.

Cette extension a vocation à simplifier la création de projets de benchmarks, l'ajout de benchmarks, et leur exécution.

Si cela vous intéresse, l'extension est disponible via le Markateplace.

Bien évidemment, son code est accessible via GitHub.

Je vous laisse vous amuser avec. Bons benchs !