Comment en finir avec les problèmes d'authentification, et MapStaticAssets?

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.

Jérémy Jeanson

L’évolution de Visual Studio 2026 qui fait la différence !

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.

Jérémy Jeanson

Utiliser xUnit avec MTP2 est possible, sous condition ...

Aujourd'hui, il est enfin possible d'utiliser Microsoft Testing Platform 2 (MTP) avec xUnit. Ceci passe par l'usage d'une version spécifique de xUnit. Cette version porte le doux nom de xunit.v3.mtp-v2 3.2.0.

La décision de créer un nouveau package a été motivée par le fait que l'usage de MTP2 avec le SDK, rendait impossible l'emploi de VSTest. Ceci est expliqué sur GitHub :

We have no timeline for if/when v2 becomes the default. For the foreseeable future, v1 will be the default, for backward compatibility (and because v2 + .NET 10 SDK purposefully breaks compatibility with people who need to use VSTest from dotnet test, which I felt was far too big a breaking change to allow v2 to become the default). In fact it's fair to say this compatibility issue was the primary driver for why I released this feature this way.

Source : XUnit.V3 compatible version for MTP 2.0.0 · Issue #3416 · xunit/xunit

Personnellement, le passage à .net core, et sa CLI m'avaient convaincu d'abandonner les appel directs à  VSTest. Mes builds .net étaient déjà compatibles avant l'arrivée de .net 10 (via DotNetCoreCLI sur Azure DevOps). Les early adopters se sentiront très peu concernés. Mais il faut reconnaitre que nombre d'entreprises ont encore du mal à faire évoluer leurs builds, et outils de builds au même rythme que .net.

Ironiquement, nous vivons une époque ou tout le monde veut parler DevOps, mais ne traite pas le sacro-saint CI / CD aussi bien que le reste.

Jérémy Jeanson

Comment changer facilement des paramètres lors de tests avec WebApplicationFactory ?

Pour des tests d'intégrations, il peut être compliqué de produire un fichier de configuration pour tester l'impacte de chaque paramètre.

Heureusement, avec WebApplicationFactory, il est possible de définir un paramètre dans son test via la méthode UseSetting.


public sealed class ProgramTests(WebApplicationFactory<Program> webApplicationFactory)
 : IClassFixture<WebApplicationFactory<Program>>
    {
        [Theory]
        [InlineData("/")]
        [InlineData("/error")]
        public async Task Test1(String url)
        {
            using HttpClient client = webApplicationFactory
                .WithWebHostBuilder(b =>
                {
                    b.UseEnvironment("xUnit");
                    b.UseSetting("Authentication:Type", "Internal");
                })
                .CreateClient();
 
	// ...
        }

Cerise sur le gâteau, contrairement à d'autres approches le paramètre est disponible avant l'ajout des services. Si votre application s'appuie sur des paramètres pour déduire les services à enregistrer, votre code devient testable.

Jérémy Jeanson

Comment contourner les petits problèmes de xUnit quand il est utilisé avec MTP ?

Depuis 3 semaines, si vous utilisez xUnit avec Microsot Testing Platform (MTP), vous rencontrez certainement quelques difficultés. Ces problèmes sont liés à l'arrivée de MTP 2. Actuellement, xUnit ne prend pas en charge cette version. Bien évidemment une issue a été créée sur GitHub. Elle peut être suivie ici : XUnit.V3 compatible version for MTP 2.0.0 · Issue #3416 · xunit/xunit

En attendant la résolution de celle-ci, il y a moyen de faire fonctionner xUnit avec MTP 1.

Le seul véritable problème consiste à comprendre comment MTP s'est retrouvé dans vos projets. En l'état, un projet de test ne référence pas directement MTP. Se sont les frameworks, et extensions qui références celui-ci. Comme toujours avec nuget, il suffit de consulter le détail d'un package pour en avoir le cœur net.

Par exemple, Microsoft.Testing.Extensions.CodeCoverage 18.1, dépends de MTP 2.0.0 à minima.

Interface nuget affichant le détail de Microsoft.Testing.Extensions.CodeCoverage 18.1

Si l'on regarde les versions précédentes de Microsoft.Testing.Extensions.CodeCoverage, on constate que la version 17.14.2 est la dernière version dépendant de MTP 1.

Interface nuget affichant le détail de Microsoft.Testing.Extensions.CodeCoverage 17.14.2

Si vous utilisez Microsoft.Testing.Extensions.CodeCoverage, il suffit donc d'installer la version 17.14.2, pour avoir une version compatible avec xUnit. Si vous utilisez d'autres extensions de MTP, il vous faudra vérifier chacune d'entre elles afin d'identifier les versions dépendants de MTP 1.

Petite astuce : avec Visual Studio, il est possible de visualiser rapidement les dépendances indirectes à des packages nuget en déroulant le nœud packages. Désolé, il n'y a pas d'équivaillent dans Rider.

Affichage des dépendances d'un projet de tests

Jérémy Jeanson