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

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.

Comme l’an dernier, la mise à jour des serveurs transactionnels openSUSE nécessite de passer par une session via shell transactional-update.

Je vous propose donc aujourd’hui une version actualisée de mon article dédié à l’upgrade d’openSUSE Leap.

Pour commencer, il faut ouvrir un Shell transactional-update afin de créer un nouveau snapshot de l'OS et le patcher.

Ceci passe par la commande :

transactional-update shell

On peut ensuite rafraichir la liste des repositories:

zypper --releasever=15.6 refresh

Lancement de la mise à jour :

zypper --releasever=15.6 dup --download-in-advance

À la fin de la mise à jour, il faut fermer le Shell :

exit

Pour finir, il faut rebooter le serveur pour que le snapshoot réalisé lors de la mise à jour soit utilisé :

reboot

Quand le serveur a redémarré, on peut utiliser la commande hostnamectl. Celle-ci affichera un message similaire à ceci :

Static hostname: xxx

Icon name: computer-vm

Chassis: vm

Machine ID: xxx

Boot ID: xxx

Virtualization: microsoft

Operating System: openSUSE Leap 15.6

CPE OS Name: cpe:/o:opensuse:leap:15.6

Kernel: Linux 6.4.0-150600.23.25-default

Architecture: x86-64

Hardware Vendor: Microsoft Corporation

Hardware Model: Virtual Machine

Firmware Version: Hyper-V UEFI Release v4.1

Firmware Date: Mon 2024-03-11

Firmware Age: 7month 4w 1d

Pour finir, il ne faut pas oublier de faire un peu de ménage dans la liste des repositories. Si vous tapez la commande zypper repos, vous vous rendrez compe que plusieurs repositories ont été désactivés (zypper repos -u, affichera un peu plus de détails, c’est une histoire de goûts).

On peut par exemple supprimer le repo lié à Leap 15.5 :

zypper removerepo openSUSE-Leap-15.5-1

Hors mis si vous vivez dans une grotte, vous n'êtes pas sans savoir qu'une nouvelle version de .net va être disponible le mois prochain. Cela fait maintenant quelques années que Microsoft publie une version majeure chaque année au mois de novembre. Cette année ne fera pas exception.

Nous aurons donc très prochainement un tout beau, et tout nouveau .net 9.

Je m'apprêtais donc à sortir ma petite série d'articles sur le sujet, dont le fameux : "Fau-il migrer...". Je préparais mes arguments, et puis je me suis rendu compte que j'avais fait une grosse erreur. Cela fait des années que je recommande de migrer le plus tôt possible afin que le travail nécessaire soit le plus simple, et le plus rapide possible. Malheureusement, je me suis rendu compte que j'avais oublié un de mes projets. Celui-ci avait été lâchement abandonné au fin fond d'un projet d'Azure DevOps depuis des années. Je ne respectais pas mon propre conseil, et je ne savais pas à quel point cela allait me couter cher.

Bien entendu, si je suis tombé sur ce projet, ce n'est pas par erreur. Il me fallait publier une nouvelle version de cette application de toute urgence sur le Google Play Store, afin que le compte développeur associé ne soit pas désactivé. Comble du bonheur, aucune des versions de .net/xamrin/android de l'époque ne peut être utilisée pour publier une application de nos jours. Je vous épargne le détail des problèmes à rallonge. La mise à jour des packages nuget ne pouvait se faire en une fois, et il fallait en remplacer quelques-uns au passage. Un vrai plaisir. Après quelques heures de travail, je pouvais enfin publier une nouvelle version de cette application. Malheureusement, je n'avais plus de temps pour ajouter de nouvelles fonctionnalités ni mettre à jour l'interface, et je me trouve avec une liste de warnings longue comme le bras (moi qui suis allergique aux warnings, c'est un comble). Sans parler de la migration vers MAUI qui n'a pas commencé.

Conclusion

Plus jamais je ne ferai cela. Que ce soit pour une application mobile, web ou autre.

Depuis .net 5, les migrations sont très rapides à réaliser si elles ont lieu tôt. Il ne faut donc pas se priver. Donc oui, il faut migrer vers .net 9, et le faire vite afin de s’éviter de gros problèmes, et des pertes de temps à rallonge.

.