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

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.

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