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

Vous souhaitez utiliser Visual Studio 2026, et ses builds tools dans votre CI / CD avec Azure Devops, mais cela ne fonctionne pas ?

Pas de panique, ce scénario est parfaitement supporté. Il suffit de mettre à jour vos agents de build avec une version 4.266.2 ou supérieure .

Petit lien ver la Release v4.266.2 · microsoft/azure-pipelines-agent

Features

• Add Visual Studio 2026 (version 18.0) support to capability detection (#5406)

Pour débuter cette nouvelle année, je souhaite vous parler d’un warning que j’affectionne tout particulièrement.

Avant d’aller plus loin, non je ne suis pas masochiste. J’e n’aime pas particulièrement les warnings, mais j’aime les résoudre. Chaque warning résolu permet d’éviter un futur problème.

Avec .net 10, un nouveau warning a fait son apparition. Le warning référencé NU1510. Celui-ci met en avant les projets qui ont des références inutiles. Il met aussi en avant la référence inutile.

Quand on aime les projets propres, c’est un must.

Petite subtilité qui me fait tout particulièrement apprécier ce warning : celui-ci met aussi en avant les dépenses transitives qui sont référencées manuellement (dans le petit monde .net on perle souvent de dépendances indirectes au lieu de dépenses transitives). Ce type de référence se produit souvent quand on souhaite forcer une montée de version suite à la découverte d’une faille sur une dépendance transitive. Quand la dépendance directe est mise à jour, et qu’elle cible la dernière version de la dépendance transitive, le warning apparait. J’adore !

Bienvenue en 2025 ! Année qui sonne le glas des architectures de microservices au profit des monolithes.

Attention : avant de me faire traiter de troll, j’annonce clairement la couleur. L’idée de cet article n’est pas de troller, mais d’affirmer un fait que nous sommes nombreux à dénoncer, et qui ne date malheureusement pas d’hier. Le microservice, ce n’est pas la panacée, et cela peut couter très cher (performances, complexité de déploiement, coûts d’exploitation). Si vous ne voyez pas ce que je dénonce, réfléchissez à ces applications réparties en 5 ou 6 conteneurs, avec presque autant de sidecars, et de conteneurs d’initialisation. On parle aussi des x frameworks pour simplifier la configuration, et l’orchestration alors que l’on utilise certainement kubernetes ? On ajoutera de l’Open Id Connect, ou toute autre solution de STS (Security Token Service) ? Les 10 repos Git pour un seul produit ?

Depuis que des sociétés comme Amazon Prime Video ont annoncé l’abandon des microservices, certains architectes ouvrent enfin les yeux. Dommage qu’il ait fallu attendre aussi longtemps.

Un nouveau mouvement émerge : l’adoption des architectures monolithiques.

Oui « monolitique ». Le mot a été lâché. Nos ayatollahs des microservices ne semblent pas avoir trouvé mieux. L’architecture monolithique qui était autrefois l’ennemie jurée devient un buzz word (pas encore au point de concurrencer l’IA, n’ayez crainte).

Il y a aussi une variante que j’aime beaucoup : « le monolithique modulaire ».

Plus sérieusement : ce que l’on veut, ce n’est pas du monolithique. On ne veut pas d'un nième tas de code spaghettis. On veut que les développeurs, et architectes fassent du KISS, du SOLID, du DRY, du YAGNI. En fait, on vous propose simplement de revenir aux solutions n tiers, avec tous les raffinements des technologies de développement modernes.

Conclusion

S’il vous plait, ne me parlez plus d’architecture monolithique. Parlez de belles solutions avec n tiers propres, évolutifs, et clairement définis (petit rappel : "n" peut être égal à 1).

Merci Amazon !

Depuis .net 9, et l'arrivée de MapStaticAssets, l’accès aux CSS, JS, et autres assets a un peu changé. Ce qui peut poser problème au moment d’ajouter une authentification a son site. Les fichiers deviennent inaccessibles. Notre belle page de login est tout de suite beaucoup moins sexy sans CSS, et sans images.

Depuis quelques mois, la documentation a été mise à jour afin de résoudre le problème, et recommander l'usage de la méthode ShortCircuit().

Exemple :

app.MapStatiAssets()
  .ShortCircuit();

L'appel de ShortCircuit() après MapStaticAssets() résout définitivement le problème, mais il supprime aussi les autres middlewares pouvant profiter à vos assets. Si vous souhaitez utiliser vos autres middlewares avec vos assets statiques, l'approche suivante est préférable :

Exemple :

app.MapStaticAssets()
  .Add(endpointBuilder => endpointBuilder.Metadata.Add(new AllowAnonymousAttribute()));

Celle-ci ajoute les metadatas utiles afin que les assets statiques soient accessibles à un utilisateur anonyme.

Dans les prochains jours, Visual Studio 2026, et .net 10 seront mis à l'honneur par Microsoft. Bien évidemment, nous serons nombreux à partager nos impressions sur ces RTM. Il a cependant un sujet qui ne va peut-être pas faire l'objet de beaucoup de communication. Je vais tenter d'y remédier ici.

Cette année, Visual Studio renforce deux de ses points forts : l'accessibilité, et l'inclusion.

De premier abord, vous ne voyez peut-être pas les points d'amélioration. Il y a certes un très gros travail sur l'UI, et l'UX. Mais quel est le lien avec l'accessibilité, et l'inclusion.

Dans Visual Studio 2026, il y a des changements très discrets, et d'autres, très prononcés :

• L'installation qui peut se faire en un click, tout en reprenant toutes les charges de travail du dernier Visual Studio installé sur le PC (ex: VS 2022).
• L'unification des interfaces les plus anciennes de VS avec l'adoption de Fluent UI (ex : écran des options entièrement revu). C'est la fin des dernières "fenêtres grises"!
• Le focus qui est encore plus marqué.
• La mise en avant du contenu qui vient de s'activer, ou qui vient d'apparaitre.
• Une navigation au clavier simplifiée (ex: moins de switshs d’un écran, ou d’un boite de dialogue à l’autre).
• Icônes, et typos très travaillés (comme toujours, l'information n'est pas transmise uniquement par l'image, ou la couleur, contrairement à d'autres IDE).
• Un bel usage des écrans larges.
• Beaucoup de petits détails mis en avant par Fluent UI.
• etc. …

Bref, dans Visual Studio 2026, le passage à Fluent UI n'a pas été un simple "restylage", ou une vulgaire surcouche. Il y a là un très gros travail d'unification de l'interface graphique, avec de belles simplifications. Attention, quand je dis cela, je ne dis pas que VS 2022, et les versions précédentes sont très compliquées. Ce sont des outils extrêmement simples d'installation, et de prise en main si on les compare à d'autres outils, et d'autres technologies. Je reconnais qu’avec VS 2026, Microsoft a trouvé le moyen de simplifier encore les choses.

Les habitués de VS ne vont pas être dépaysés. Ils profiteront vite des nouveautés, et seront heureux de voir disparaitre quelques très anciennes fenêtres. Les nouveaux utilisateurs vivront une première expérience très fluide, et simple, car tout tombe sous la main ou presque. Sinon, il suffit de demander à Copilot  (même si la recherche classique subsiste).

Les personnes en situation de handicap devraient elles aussi trouver leur bonheur. Dys, et aveugles devraient constater une belle évolution. En tout cas, je valide pour une partie des daltoniens. Désolé je ne peux pas donner de détails. Je ne connais pas mon type de daltonisme, car les ophtalmologistes n'arrivent pas à le déterminer.

Pour résumer simplement : Microsoft a utilisé Fluent UI, et ses règles d'accessibilité pour simplifier les choses, et réduire la charge mentale liée à l'usage de l'outil. C'est beau, et c'est bien fait.

Simplicité d'usage + belles performances. Je crois que Microsoft a trouvé le combo gagnant.