A la rencontre de .NET 6

En novembre 2020, Microsoft sortait .NET 5, sa nouvelle plateforme unifiée née de la fusion du framework .NET, .NET Core et Mono/Xamarin renommée simplement ".NET" pour l'occasion. Un an après, la nouvelle mouture de Microsoft, .NET 6, amène avec elle son lot d'évolutions.

L'objectif "One .NET" est clair : proposer la meilleure plateforme unifiée permettant de répondre aux multiples types d'applications avec un maximum de code partagé. Le mot d'ordre est donc à l'unification dans la lignée de ce qui a été initié avec .NET 5 (mais pas que) …

Vue d’ensemble de .NET 6

Lors de la planification de cette nouvelle version (.NET 6) fin 2020, Microsoft s'est appuyé sur 8 thèmes, chaque thème regroupant des fonctionnalités correspondant à un concept cible auquel le framework doit répondre[1] :

  • ".NET doit être attrayant pour les nouveaux développeurs/étudiants" : fournir une expérience lissée pour les personnes qui intègrent l'écosystème à l’aide d’une suite d’outils adaptés, d’une documentation complète et claire, ainsi que de concepts simplifiés.
  • ".NET propose une bonne expérience de développement d'applications clientes" : fournir un framework d'applications clientes multiplateformes qui permet de livrer des applications, de manière homogène, sur bureau, mobile et web, construites sur/avec les types d'application existants Blazor/Xamarin.
  • ".NET est reconnu comme un framework convaincant pour créer des applications cloud natives" : fournir les fonctionnalités fondamentales native-cloud qui prouvent la valeur du framework dans des cas d'utilisation cruciaux.
  • "Entreprise et LTS" : mieux adresser les besoins des grandes entreprises et gouvernements.
  • "Faire grossir l'écosystème .NET à l'aide d'une qualité, d'une confiance renforcée et d'un support amélioré" : établir une communauté .NET pérenne afin d’élever le niveau de connaissance des membres de la communauté vis-à-vis de celui de Microsoft.
  • "Améliorer la productivité des développeurs" : rendre le développement d'application .NET plus efficace.
  • "Améliorer les performances en utilisant les informations d'exécution du runtime (PGO)" : fournir un framework performant sur le lancement d’applications, les débits de données ainsi que sur la taille réduite des binaires.
  • "Répondre au mieux aux attentes des développeurs" : améliorer .NET et créer de nouveaux scénarios d'usage à partir des retours utilisateurs.

Le contenu de cette nouvelle release met l'accent sur plusieurs axes. Tout d'abord, la continuité de l'unification de la plateforme (entrepris avec l'arrivée de .NET 5) qui vise le développement multiplateforme mobile, bureau et web tout en minimisant l'effort de cibler plusieurs plateformes. Autre sujet très important pour Microsoft, le cloud ! .NET 6 apporte de nouvelles fonctionnalités native-cloud afin d'améliorer la valeur du framework dans les cas d'utilisation cloud. Les développeurs ne sont pas en reste : Microsoft prévoit d'améliorer la productivité du cycle de développement des applications .NET 6 ainsi qu’une meilleure prise en compte des retours utilisateurs afin que le framework réponde au mieux à leurs attentes. Pour finir, Microsoft continue de s'ouvrir à la communauté open-source : c'est dans cette optique qu'une attention particulière est portée sur l'évolution de la communauté .NET. En effet, la firme de Redmond vise à élargir le nombre de développeurs qui utilisent .NET 6 en simplifiant/accélérant la mise en place de certains cas d’utilisation (qui pouvait rebuter certaines personnes venant d’autres langages) et en accueillant au mieux les “nouveaux arrivants” autour d’un écosystème simple et accessible.

Cette nouvelle version du framework était prévue pour novembre 2021 avec un support long terme (Long Term Support) de 3 ans.

Les nouveautés majeures

Dans les faits, .NET 6 apporte de nombreuses nouveautés ; voici une sélection des nouveautés « majeures » :

  • Développement multiplateforme
    • .NET MAUI (Multi-platform App UI)
    • Application Blazor desktop
    • Amélioration du support des processeurs Arm64
  • Amélioration de la productivité
    • Nouvelle fonctionnalité de "Hot reload" ("rechargement à chaud")
    • Amélioration des performances du build
  • Développement d'applications cloud-native
    • ASP.NET Core Minimal web APIs
  • Evolution du SDK
    • Logique de workloads optionnels
  • Amélioration des performances du runtime

.NET 6 sera accompagné de la nouvelle version de C# 10 (qui vise notamment à simplifier et minimiser le code à produire) et de la plus fraîche des versions de son éditeur phare : Visual Studio 2022. Cette dernière sera d’ailleurs requise pour espérer travailler avec la dernière version du framework.
 

Les plateformes supportées par .NET 6

Premièrement, jetons un œil à la liste des plateformes supportées par .NET 6.

Pour Windows, peu de changement : .NET 6 supporte exactement les mêmes versions que .NET 5 mais introduit le support de Windows Arm64 (spécifique à Windows Desktop). En ce qui concerne Linux, quelques modifications sont à noter : la disparition de Linux Mint de la liste des distributions supportées et la montée de version pour d’autres (Alpine Linux : 3.11+ > 3.13+ et support d’ARM32, Debian : 9+ > 10+, support d’Arm64 pour Red Hat). Au tour de macOS qui voit sa version passer de 10.13+ à la 10.14+ mais aussi (et surtout) le support de l’architecture Arm64 (et donc la prise en charge des nouveaux processeurs Apple Silicon M1). Pour finir, on note bien sûr l’apparition des versions Android et iOS/tvOS.

Plus d’informations ici : https://github.com/dotnet/core/blob/main/release-notes/6.0/supported-os.md

 

.NET MAUI (write-one run-everywhere)

Présentation

.NET MAUI signifie .NET Multi-platform App UI. Ce framework cross-platform permet de créer des applications mobiles natives ainsi que des applications bureau en C#/XAML. Il est ainsi possible de construire des applications iOS, Android, macOS et Windows à partir d'une base de code commune. Cela afin de maximiser la réutilisation entre les différentes applications plateforme et ainsi optimiser les temps/coûts de développement.

 

.NET MAUI se base sur Xamarin.Forms : celui-ci a été étendu afin de prendre en charge la création d'applications bureau. Un projet .NET MAUI permet de créer plusieurs applications par plateforme au sein d'un même projet. Le framework met à disposition une API cross-platform permettant d'accéder aux fonctionnalités natives des plateformes ciblées telles que :

  • L'accès aux capteurs (gyroscope, accéléromètre, compas…)
  • La possibilité d'avoir des informations sur l'état de la connexion
  • Le copier/coller système entre les applications
  • Le stockage sécurisé d'informations
  • L'utilisation du "speech-to-text"
  • L'accès aux informations de l'appareil

Bien que les différentes applications se basent sur du code commun et une API cross-platform, il est tout à fait possible d'agrémenter chacune des implémentations par l'utilisation de code spécifique à telle ou telle plateforme (et par conséquent d'utiliser les capacités natives propres à une plateforme). De plus, Microsoft mentionne que, dans un souci de performances et d'extensibilité, l'ensemble des contrôles UI ont été réimplémentés de zéro.

Comment ça se passe sous le capot ?

.NET MAUI expose une API unique pour l'ensemble des plateformes disponibles à savoir : iOS, Android, macOS et Windows. De son côté, .NET 6 implémente une série de frameworks spécifiques à chaque plateforme :

  • .NET pour iOS
  • .NET pour Android
  • .NET pour macOS
  • WinUI pour Windows

L'ensemble de ces frameworks repose sur une bibliothèque commune fournie là aussi par .NET 6 : la BCL ou "Base Class Library". A son tour, cette bibliothèque repose sur les différents runtimes (Mono Runtime pour iOS, Android et macOS, WindowsRT pour Windows) afin de fournir l'environnement d'exécution pour le code de l'application. Bien que l'implémentation de chacune des plateformes soit abstraite, il n'en demeure pas moins qu’elles ont leur propre manière de gérer certains éléments (notamment dans la manière qu'elles ont de définir et d'afficher les éléments graphiques). Dans le cas particulier où l'API exposée ne répondrait pas à un besoin spécifique, .NET MAUI offre la possibilité d'interagir directement avec les frameworks correspondant à chacune des plateformes : dans ce cas précis, charge aux développeurs de maintenir ce code à jour pour chacune des plateformes.

Et puisque qu'une image vaut mieux qu'un long discours, vous trouverez ci-dessous un schéma récapitulatif de la structure de .NET MAUI fourni sur la documentation Microsoft.

 

  1. Interaction entre le code applicatif et l'API .NET MAUI
  2. Interaction directe entre le code applicatif et l'un des frameworks spécifiques aux plateformes
  3. Interaction entre la couche .NET MAUI et les framework spécifiques aux plateformes (abstraction des interactions avec les frameworks par l'intermédiaire de l'API .NET MAUI)

A noter que toutes les applications créées autour du framework .NET MAUI peuvent être packagées en application native. .NET MAUI supporte le "hot reload" sur le .NET et XAML (cf. "Hot reload" pour plus d'informations).

.NET 6 & Arm64

L’architecture Arm64 reste un sujet très important pour Microsoft. Avec la sortie des machines Apple équipées du nouveau processeur M1 à architecture Arm64, l’enjeu est important dans le contexte d’applications cross-platform. De nombreux efforts ont été accomplis sur la dernière release du framework afin d’améliorer la gestion de cette architecture. Dans cette nouvelle version, Microsoft continue d’investir sur les aspects performances et fonctionnalités.

Sur Windows, .NET 6 ajoute le support pour Windows Forms et Windows Presentation Foundation (WPF) par-dessus les capacités Windows Arm64 poussées en .NET 5. Il est prévu que ces fonctionnalités soient redescendues sur .NET 5 par la suite.

Sur Mac, les puces Apple Silicon sont désormais supportées. Ces puces ont deux modes de fonctionnements : natif et émulé (x64). L’émulation est implémentée par l’intermédiaire du composant Rosetta 2, un logiciel Apple qui permet à des applications compilées uniquement pour des processeurs x86/x64 d’être traduites, pour être ensuite exécutées sur des processeurs Apple Silicon. Cette émulation entraîne bien sûr une répercussion sur les performances par rapport à une exécution native.

.NET 6 fournira des builds Arm64 et x64 là où les anciennes versions de .NET et .NET Core ne fournissent que des builds x64 (qui se basent sur Rosetta 2 afin de tourner sur les machines équipées d’Apple Silicon).

A priori, le support des puces Apple Silicon n’est pas prévu d’être porté sur .NET 5 ou les versions plus anciennes de .NET Core.

Applications Blazor desktop

Blazor prend de plus en plus de place pour la création d'applications web en .NET. Après avoir été initialement une technologie côté serveur puis portée côté client, il est désormais possible de créer des applications bureau à partir de celle-ci. Blazor desktop permet de créer des applications natives qui mêlent web et interfaces utilisateurs natifs. Microsoft indique qu'il a vocation à être utilisé par des profils de développeurs web qui souhaitent proposer des clients lourds et/ou une expérience hors-ligne.

Blazor desktop peut être utilisé pour des fonctionnalités ciblées au sein d'une autre application native (par exemple une application réalisée en WPF). Il est ainsi possible de réutiliser un composant déjà développé pour un site web basé sur Blazor directement dans cette autre application. Il existe donc désormais de nombreuses façons d'exécuter du Blazor. Il conviendra d'analyser ces différentes possibilités afin de sélectionner la plus propice à chacun des projets.

Blazor desktop est construit par-dessus .NET MAUI, ce qui lui permet de gérer l'affichage et de manipuler les fonctions natives de l'appareil. Microsoft mentionne que Blazor desktop est similaire à Electron JS dans sa structure : il fournit un contrôle WebView qui sera chargé du rendu par l'intermédiaire d'un serveur Blazor embarqué qui sera capable de servir les contenus Blazor (ainsi que les ressources de types JavaScript, CSS…).

Hot reload

Un des grands piliers poussés par Microsoft est l'optimisation du cycle de développement des applications autour de son framework. C'est dans cette optique qu'une nouvelle fonctionnalité appelée « Hot reload » fait son apparition (ou « rechargement à chaud » pour les puristes de la langue française). Initialement mis en place par les équipes en charge de Xamarin pour le rechargement à chaud du XAML, il a été décidé de généraliser ce concept à l'ensemble du framework.

Avec cette fonctionnalité, le développeur peut modifier le code de ses applications (code managé uniquement) pendant que celles-ci sont en cours d'exécution. Les modifications sont alors directement prises en compte et propagées sur l'application déjà lancée.

Pour cela, il suffit de réaliser une modification dans le code et de cliquer sur le nouveau bouton « Apply Code Changes » (« appliquer les changements ») dans Visual Studio afin d’appliquer ces modifications.

 

Microsoft mentionne que le « Hot reload » est supporté pour de nombreux types de projet tels que les applications WPF, ASP.NET Core (code-behind), console, WinUI3… Il est aussi disponible sur l’ensemble des applications qui sont basées sur les runtimes du Framework .NET et CoreCLR.

Avec .NET 6, le rechargement à chaud est disponible à partir de la ligne de commande dotnet watch. Pour rappel, l’utilitaire dotnet watch permet de surveiller les fichiers du projet pendant l’exécution afin de redémarrer celui-ci si une modification est apportée à un fichier. Désormais, les modifications seront rechargées à chaud sans redémarrage : à noter que dans le cadre de modifications nécessitant obligatoirement un redémarrage dotnet watch devrait demander une confirmation préalable du développeur.

Minimal Web API & native-cloud

Microsoft souhaite faire du framework .NET un produit de premier choix lorsqu’il s’agit de produire une application cloud-native. Et cela passe forcément par une méthode de création simple et rapide de service. Jusqu’ici, la création des services nécessitait un certain nombre de codes d’initialisation : même pour la plus simple des API. Avec .NET 6, c’est désormais du passé avec l’arrivée des “minimal web API”. Le concept est simple : avoir la possibilité de créer des services rapidement avec un minimum de code. Cela est particulièrement pratique pour les applications de type micro-services qui exposent de nombreuses API au scope limité.

Désormais la création d’un projet web :

dotnet new web

Génère le fichier unique suivant :

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/hello", () => "Hello, World!");
 
app.Run();
  • À la disparition du fichier Startup.cs
  • Aux déclarations top-level dans le Program.cs (pas d’espace de nom, de classe ou de déclaration de méthode)
  • Au nouveau modèle d’hébergement WebApplication.CreateBuilder
  • Et à la mise en place des usings implicites

Ci-dessous, voici un exemple qui compare la quantité de code à écrire afin de mettre en place un service avec l’initialisation de Swagger/OpenAPI entre les versions ASP.NET Core Web API en .NET 5 et ASP.NET Core Web API en .NET 6 :

  • Initialisation en ASP.NET Core WebAPI .NET 5
  • Initialisation en ASP.NET Core WebAPI en .NET 6
var builder = WebApplication.CreateBuilder(args);


builder.Services.AddControllers();
builder.Services.AddSwaggerGen(c =>
{
    c.SwaggerDoc("v1", new() { Title = "WebApplication22", Version = "v1" });
});
 

var app = builder.Build();
 

if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI(c => c.SwaggerEndpoint("/swagger/v1/swagger.json", "WebApplication22 v1"));
}
 

app.UseHttpsRedirection();
 

app.UseAuthorization();
 

app.MapControllers();
 

app.Run();

 

A noter que l’ancien modèle d’hébergement ainsi que le pattern Startup continueront d’être supportés.

 

Bibliothèques

La bibliothèque de fonctionnalités du framework a été elle aussi enrichie pour cette nouvelle version. En voici un florilège :

Math

Un nouvel ensemble API mathématique fait son apparition dans System.Math (SinCos, ReciprocalEstimate...). Ces API sont orientées performance et seront accélérées par le hardware (si celui-ci le supporte). Le parsing des formats numériques standard et des BigInteger a, quant à lui, été amélioré.

JSON

.NET 6 agrémente la gestion du JSON de quelques fonctionnalités. Une nouvelle option ReferenceHandler.IgnoreCycles permet d’ignorer les références cycliques lors de la sérialisation. Une fois activée, les références cycliques seront remplacées par le token JSON null (contrairement à Newtonsoft.Json qui ignore la référence dans ce cas).

Il est désormais possible de (dé)sérialiser avec un IAsyncEnumerable<T> et d’utiliser des notifications exposées par le sérialiseur (au travers de l’implémentation des interfaces IJsonOnDeserialized, IJsonOnDeserializing, IJsonOnSerialized ou IJsonOnSerializing). Les propriétés d’un objet peuvent, dès à présent, être ordonnées lors de la sérialisation à l’aide de l’attribut System.Text.Json.Serialization.JsonPropertyOrderAttribute.

La nouvelle API « writable JSON DOM feature » offre la possibilité de modifier/requêter et transformer de grands arbres de données JSON et ce de manière performante. L’API propose aussi une syntaxe plus élégante et plus naturelle pour définir des objets JSON. A l’aide de celle-ci, il est aussi possible d’utiliser le mot clé dynamic qui permet l’utilisation de modèles faiblement couplés.

Pour finir, .NET 6 intègre une génération de source pour le JsonSerializer : l’idée est de générer le code source lors de la compilation afin d’éviter le processus d’analyse par réflexion qui a lieu au lancement de l’applicatif. Cela a pour effet de réduire le temps de lancement, d’améliorer les débits de sérialisation, de réduire l’empreinte mémoire et de supprimer l’utilisation de la réflexion au runtime.

LINQ

System.Linq introduit, lui aussi, des améliorations. Enumerable.ElementAt peut désormais prendre en paramètre un index partant de la fin de l'énumérable :

Enumerable.Range(1, 10).ElementAt(^2)

Dans la même veine, Enumerable.Take accepte un Range en entrée :

source.Take(..3) pour source.Take(3)

source.Take(3..) pour source.Skip(3)

source.Take(2..7) pour source.Take(7).Skip(2)

source.Take(^3..) pour source.TakeLast(3)

source.Take(..^3) pour source.SkipLast(3)

source.Take(^7..^3) pour source.TakeLast(7).SkipLast(3)

La nouvelle méthode TryGetNonEnumeratedCount tente de récupérer le nombre d'élément d'un énumérable sans réaliser d’énumération. Cette méthode vérifie si la source implémente ICollection/ICollection<T> ou tire avantage des optimisations internes propres à LINQ.

DistinctBy/UnionBy/IntersectBy/ExceptBy offrent de nouvelles variantes autorisant de spécifier une égalité en utilisant un sélecteur de clé et MinBy/MaxBy permettent de trouver le maximum/minimum à partir d'un même sélecteur de clé. La méthode Chunck permet de diviser un énumérable en tableau d'une taille fixe passée en paramètre :

IEnumerable<int[]> chunks = Enumerable.Range(0, 10).Chunk(size: 3);

// { {0,1,2}, {3,4,5}, {6,7,8}, {9} }

 

Jusqu'alors les méthodes FirstOrDefault/LastOrDefault/SingleOrDefault retournaient un default(T) si l'énumérable ne contenait aucune valeur. En .NET 6, il est possible de définir cette valeur de retour par défaut qui sera retourné si la source est vide. Pour terminer sur les Enumerable, Enumerable.Zip rend possible la fusion des trois énumérables en une série de tuple.

Autres

On note aussi pêle-mêle :

  • Une nouvelle implémentation du FileStream (qui améliore les performances sur Windows)
  • Une meilleure gestion des Date, Time et TimeZone et une meilleure gestion des struct en tant que valeur dans les dictionnaires
  • L’amélioration de la vérification et du cast des interfaces
  • Le support des nint/uint pour Vector<T>
  • Une nouvelle structure PriorityQueue
  • L’apparition de nouveaux algorithmes de cryptage (ChaCha20 et Poly1305)
  • Le support d’OpenSSL3 et d’OpenTelemetry Metrics API
  • Une nouvelle implémentation du .NET thread pool

SDK

Avec l'arrivée de nouvelles plateformes supportées et l'ajout de nombreuses nouvelles fonctionnalités, on peut se poser la question de la taille du SDK qui ne cesse de grossir, notamment avec les nouveaux workloads mobiles.

Microsoft y a pensé et a introduit dans .NET 6 la notion de « workload optionnel ». L’idée est de passer d’un SDK monolithique vers de la composition de SDK. Il est ainsi possible d’ajouter de façon plus granulaire les éléments supplémentaires que chaque développeur souhaite installer dans son SDK. Cette fonctionnalité s’accompagne d’une ligne de commande dédiée :

dotnet workload

Cette ligne de commande permet d’installer, de désinstaller, de lister les workloads installés ou encore de les mettre à jour. Les workloads pourront aussi être manipulés par l’intermédiaire de l’installeur Visual Studio ou encore du gestionnaire de paquet de Linux.

Le SDK devrait d'ailleurs à terme perdre du poids car certains workloads déjà existants passeront dans un futur proche eux aussi optionnels. La firme de Redmond indique que cette nouvelle expérience "workloads SDK optionnels" sera présente dans .NET 6 et finalisée dans la prochaine version (c’est-à-dire .NET 7).

Dans la même optique, un outil permettra désormais de vérifier si une nouvelle version du SDK et des runtimes est disponible. Pour cela, rien de plus simple, il suffit d’utiliser la commande suivante :

dotnet sdk check

Pour chacune des plages de fonctionnalités, il indique la dernière du SDK/runtime disponible et si les versions installées sont à jour.

 

Passer à .NET 6

Modification avec rupture

Avant de passer sur .NET 6, il est prudent d'analyser les changements qui créent une rupture avec les versions précédentes et qui nécessitent des modifications dans le code. Voici une sélection des modifications de ruptures marquantes (breaking changes) :

Réseau

  • Les classes WebRequest, WebClient et ServicePoint sont désormais dépréciées.

ASP.NET Core

  • Les noms d’espace Security.Permissions et System.Windows.Extension ont été retirés des packs de ciblage et du runtime ASP.NET Core. Les noms d’espace Microsoft.Win32.SystemEvents et System.Drawing.Common ont, quant à eux, été supprimés du pack runtime d’ASP.NET Core, dans un but de réduire la taille du framework partagé d’ASP.NET Core.
  • Le package permettant le support de MsgPack pour SignalR sur ASP.NET Core change de version. La dépendance du package npm @microsoft/signalr-protocol-msgpack passe de msgpack5 vers @msgpack/msgpack. De plus, l’interface MsgPackOptions voit ses champs disableTimestampEncoding et forceFloat64 supprimés.
  • L’intergiciel de redirection HTTPS renvoie une exception s’il existe plusieurs ports définis dans la configuration : ceci pour éviter de possibles envois de données sensibles en HTTP lorsque HTTPS est disponible.
  • Une nouvelle surcharge de Use a été ajoutée à la release. Si le code de l’application appelle app.Use sans que l’intergiciel correspondant n’appelle l’intergiciel suivant (en utilisant await next()) alors une erreur de compilation sera levée. Dans ce cas, il sera nécessaire de le remplacer par app.Run. Exemple de code nécessitant une modification :
app.Use(async (context, next) =>
{
    await SomeAsyncWork();
    // next n'est pas appelé...
});

Razor

  • Le compilateur Razor ne crée plus d’assembly séparé dll contenant les vues CSHTML de l’application. Désormais, un seul assembly contenant les types de l’application ainsi que les vues est généré (par défaut les vues générées ont les modificateurs d’accès internal ou sealed et sont placées sous le nom d’espace AspNetCoreGeneratedDocument).
  • Les types relatifs au type RazorEngine sont désormais obsolètes.

Blazor

  • Modification d’une coquille résiduelle dans le nom du champ maxWith qui passe à maxWidth.
  • L’interopérabilité avec les tableaux d’octet a été revue : il n’est désormais plus nécessaire de décoder l’entrée à partir de la Base64 :
function receivesByteArray (data) {
    // data est désormais un Uint8Array > plus besoin de décoder la Base64
}
  • Le LongPolling n’est plus utilisé en solution de repli si les WebSockets ne sont pas disponibles (problèmes réseau ou non compatibilité par exemple). Le client et le serveur supportent désormais uniquement les WebSockets : un message d’erreur est renvoyé dans les cas où au moins l’un des deux parties ne supporte pas les WebSocket.

Bibliothèque Core .NET

  •  L’équipe .NET abandonne le support des frameworks plus anciens que .NET Framework 4.6.1, .NET Core 3.1 et .NET Standard 2.0. Si un projet référence un paquet d’un framework antérieur, il ne sera plus possible de mettre à jour ce paquet vers une version ultérieure.
  • Le comportement de la propriété ProcessorCount sur Windows (qui fournit le nombre de processeurs disponibles pour le processus courant) est désormais aligné avec le comportement sur Linux. Auparavant celui-ci retournait le nombre de processeurs logiques sans prendre en compte l’affinité des processus ni les limitations d’utilisation des CPUs. Le code dépendant de cette propriété sera donc peut-être à revoir.
  • La propriété Position est mise à jour une fois que les opérations de ReadAsync/WriteAsync sont terminées contrairement à avant où elle était mise à jour une fois les opérations démarrées.
  • Microsoft informe qu’avec les surcharges ajoutées à la classe Linq.Queryable, il peut y avoir un impact sur du code utilisant la réflexion si celui-ci n’est pas assez robuste. Par exemple :
typeof(System.Linq.Queryable)
    .GetMethods(BindingFlags.Public | BindingFlags.Static)
    .Where(m => m.Name == "ElementAt")
    .Single();

Pour consulter la liste exhaustive des modifications avec ruptures, c’est par ici : https://docs.microsoft.com/en-us/dotnet/core/compatibility/6.0.

 

Migration vers .NET 6

Microsoft va mettre à disposition un utilitaire facilitant la mise à jour d'un projet vers la dernière version du framework : .NET Upgrade Assistant (pour l’instant en version « Preview » dont la release est attendue avec la sortie de .NET 6).

Cet outil analyse un projet et propose des instructions étape par étape afin de réaliser sa migration dans les meilleures conditions et de manière incrémentale. Il est capable d’analyser les packages nuget et où sont les dépendances. Il prodigue des conseils, des recommandations ou encore des corrections pour les fichiers de configuration, de projets et du code source.

Pour l’instant, la liste des projets supportés est limitée (d’autres types viendront compléter cette liste par la suite) :

  • ASP.NET MVC
  • Windows Forms
  • Windows Presentation Foundation
  • Console
  • Bibliothèque

Le rythme de livraison autour du framework s’est accéléré : il est prévu à une release par an. Il va donc être essentiel de tenir à jour les applications basées sur .NET afin de ne pas prendre trop de retard sur les différentes livraisons et de bénéficier des dernières nouveautés. Microsoft s’en rend bien compte et essaie de faciliter au mieux ces montées de version. A voir comment évoluera cette problématique qui sera un enjeu majeur pour les futures évolutions du framework et donc l’adoption de celui-ci.

 

Conclusion

.NET 6 s'inscrit dans la lignée directe du travail d'unification initié dans .NET 5. De nombreuses améliorations ont été apportées d’un point de vue fonctionnalités mais aussi au niveau des performances. Des efforts ont été faits afin de rendre l’expérience autour du framework plus accessible. Microsoft souhaite attirer de nouveaux développeurs et ainsi étoffer la communauté .NET. Cela a pour objectif de placer .NET comme un concurrent légitime et polyvalent !

Reste à voir l’impact qu’auront les apports de cette nouvelle version sur la communauté. L'adoption sera-t-elle au rendez-vous ?

 

[1] cf. https://themesof.net/

 

Article initialement paru dans Programmez! #249