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

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 !

Windows Server 2025 apporte beaucoup de bonnes choses. Mais il n'intègre toujours pas d'interface graphique pour la création d'un switch virtuel basé sur SET (Switch Embedded Teaming). Ceci est un peu dommage, car le NIC Teaming historique est parfaitement intégré à la console de gestion du serveur. Avec une petite dose d'adaptation, son interface graphique pourrait pourtant être réutilisée pour le SET. Cela ne serait pas choquant.

Il est un temps que les moins de vingt ans ne peuvent pas connaitre. Je vous parle d'un temps où les développeurs utilisaient Windows Server comme OS pour leur PC (même sur leurs portables). Un temps où il était impossible de développer pour SharePoint sans cet OS. Un temps où il était inimaginable d'utiliser Visual Studio dans une machine virtuelle... etc.

Nombre de développeurs ne connaissent pas cette époque, car Microsoft a rendu possible 100% des tâches de développement possible avec un simple OS client. Progressivement, une nouvelle génération de développeurs s'est installée, et Windows Server n'a plus trouvé sa place que sur nos serveurs.

Et, Zorro est arrivé...

Pardon, je m'emballe. Windows Server 2025 est arrivé.

Depuis sa publication en RTM le 1er novembre 2024, je trouve dommage que les blogueurs Dev / DevOps ne publient pas de contenus. Je vais tenter de changer cela. Mais pour commencer, je vais aller en douceur. Je ne vais pas m'attaquer à l'aspect serveur, qui contient quelques modifications qui risquent d'avoir un impacte sur vos applications (ex: TLS 1.3 pour LDAPS, pas cool pour certains frameworks).

Attaquons le côté ludique de Windows Server 2025, et ce qui va avoir un intérêt pour les développeurs. Voici mon top 3.

1. UI / UX

L'une des grandes nouveautés est l'adoption des codes d'UI/UX de Windows 11. Fini l'obligation de passer par telle ou telle interface vieillotte, et l'obligation de maitriser les MMC. Cela va grandement simplifier la configuration pour les néophytes (sans parler du débogage). L'un des aspects les plus sympathiques se cache justement dans cette interface : "For developers".

2. DevDrive

Le menu System a une entrée "For developers" qui contient les mêmes options que Windows 11.

Ce qui m'intéresse du côté de cet UI, c'est la possibilité d'utiliser DevDrive :

Cette fonctionnalité étant aussi sur Windows 11, vous demandez peut-être pourquoi je suis intéressé par le fait de la retrouver sur Windows Server. Effectivement, celle-ci n'est pas un motif suffisant pour installer un OS serveur sur un PC de Dev. Par contre, elle peut légitimer la migration de serveurs de builds. Utiliser DevDrive peut aider à réduire les temps de builds, et la durée d'exécution des pipelines Azure DevOps sur les agents autohébergés.

3. CLI

Winget est enfin de la partie. Il est installé par défaut. Ceci qui va permettre d'automatisé la mise à jour du tooling des serveurs de builds, déploiement, ou test. Un point de plus pour le DevOps!

Pour les allergiques à PowerShell Remoting, Microsoft a installé le serveur SSH par défaut. Il ne reste qu'à l'activé via la console Server Manager.

Azure ARC est aussi installé par défaut. Ce qui va faciliter les intégrations à Azure. Il ne reste qu'à le configurer.