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

Nous avons beau être en 2025, nombre d’entreprises doivent maintenir des solutions .net Framework. Ce n’est pas une tare. J’en connais même qui maintiennent des applications écrites en VB6, et VBA.

Mais ce n’est pas parce que l’on dépend de .net Framework qu’il faut pour autant se sentir abandonné. Microsoft publie régulièrement des correctifs, et Visual Studio continue de supporter le Framework.

D’ailleurs, nombre de fonctionnalité de la CLI dotnet 9 sont utilisable avec .net Framework. Pour preuve, je vous propose aujourd’hui trois actions à réaliser au plus vite afin de mieux profiter de .net Framework, dotnet.exe, et ViSual Studio 2022 :

• Migrer vos projets vers le format SDK.
• Migrer vos fichiers sln, vers le format slnx.
• Utiliser des packages nuget de .net 9.

Les deux premières vont améliorer les performances de Visual Studio, et faciliter les fusions (l’intelligence est aussi beaucoup plus réactive).

Note : la migration du format csprog / vbproj, peut être facilitée via le .net Upgrade Assistant. Celui-ci peut servir à changer que le format du projet. La migration de .net Framework à .net 8 ou 9, n’est pas forcée.

La dernière proposition quant à elle va vous permettre d’abandonner nombre d’API de .net Framework qui sont aujourd’hui un peu dépassées (sérialisation, cryptographie, authentification, etc.)

Je constate avec beaucoup de plaisir qu’il y a un très fort engouement de la communauté .net autour du format de solution SLNX. Je ne reviendrai pas sur l’intérêt de ce nouveau format. Je crois que tout a déjà été dit sur le sujet. Il est évident que le SLNX va très vite s’imposer.

Cependant, il ne faudrait pas mettre la charrue avant les bœufs :

• Oui, sur le plan technique, on peut tous adopter ce nouveau format.
• Non, sur le plan pratique, tout le monde ne peut pas l’adopter de suite.

Vous allez me dire : “ C’est du Jérémy tout craché. Il ne peut pas dire oui sans dire non “. Vous n’aurez pas totalement tort. Dans le cas présent, ma réserve s’appuie sur les bases suivantes :

• Le tooling utilisé par les développeurs doit être compatible.
• Le tooling utilisé pour les builds doit être compatible.

Ces deux conditions doivent être remplies, et les outils doivent être déployés avant de commencer la migration. Faute de quoi, il y aura des problèmes.

Attention : ce n’est pas parce qu’un outil est compatible que l’opération se fera toute seule. Exemple : Visual Studio 17.13 supporte les SLNX, à condition d’activer la fonctionnalité via le menu des options (fonctionnalité qui est stable, mais toujours cataloguée en « preview » ).

De plus, si vous avez à maintenir plusieurs versions majeures de vos applications, il faudra fusionner très vite les branches relatives à la migration pour éviter d’autres problèmes.

Depuis quelque temps déjà, il est possible d’utiliser Windows Update pour maintenir Visual Studio à jour.

Mais est-ce une bonne idée ?

Très honnêtement, cela dépend. J’ai bien conscience que personne n’apprécie ce genre de réponse. Mais il faut être factuel. Tout dépend de la manière utilisée pour administrer les PC des développeurs.

Par défaut

Si cette fonctionnalité est activée et gérée par librement par le développeur, l’expérience est fluide :

• Les mises à jour sont téléchargées en tâche de fond.
• Les mises à jour ne sont pas installées durant les périodes d’activités (horaires configurables via Windows Update).
• Les mises à jour ne sont pas appliquées si Visual Studio est utilisé.

En somme tout va bien.

Configuration centralisée

Si la mise à jour est pilotée par vos administrateurs : « ça passe, ou ça casse ». Microsoft a offert tellement de possibilités pour piloter les mises à jour, qu’il est très facile de se tromper. Si vous avez l’intention de centraliser les mises à jour, je vous conseille vivement de mettre en place une approche similaire à ceci :

• Mettre en place un groupe de développeurs pilotes (avec qui échanger sur les besoins et usages de Visual Studio).
• Mettre en place une stratégie de déploiement progressive (avec des tests sur un nombre de PC restreints)
• Ne pas chercher à modifier trop d’options à la foi.
• Tester, tester, tester !

Le secret réside dans l’échange, et le test. Une mise en place trop brutale en ne considérant que l’aspect « applications des mises à jour de sécurité » est vouée à l’échec (indisponibilité de Visual Studio, outil inutilisable, impossibilité d’ajouter des fonctionnalités dépréciées, etc…).

Pour aller plus loin

Voici quelques liens très intéressants :

• Keep Visual Studio automatically updated and secure through Microsoft Update.
• Deploy Visual Studio updates to devices enrolled in Windows Update for Business.
• Enable Group Policy Settings with Visual Studio Administrative Templates (ADMX).
• Guide de l’administrateur Visual Studio

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.