Discussion :

[Bill Fassinou]

Microsoft publie .NET 6 Preview 1 avec le support de Blazor pour les applications desktop
des améliorations de performances et quelques nouvelles fonctionnalités

Microsoft a publié mercredi le premier aperçu de .NET 6, successeur de .NET 5 publié en novembre dernier. .NET 6 sera lancée en novembre 2021 et représente l'aboutissement d'un effort de plusieurs années visant à fournir un framework multiplateforme à code source libre pour tout ce qui concerne .NET dans une offre globale unifiée. Dans .NET 6, l'équipe de développement se concentrera spécifiquement sur les performances des applications, l'ajout de nouveaux thèmes de contrôle et l'accélération des expériences des développeurs. Voici ce que Microsoft prévoit dans .NET 6.

.NET 6 : Microsoft promet une plateforme unifiée et étendue

Microsoft cherche depuis quelques années maintenant à unifier et à étendre la plateforme .NET. Selon, Richard Lander, Program Manager au sein de l'équipe .NET, cet effort, consistant à transformer l'ancien framework .NET, initialement réservé à la création d'applications pour Windows, en un produit moderne, a commencé avec .NET Core et s'est poursuivi avec .NET 5, qui était censé unifier le .NET avec un lancement en novembre 2020. Cependant, cette dernière a échoué en raison de la pandémie du coronavirus et d'autres problèmes survenus au cours de l'année.

Ainsi, .NET 6 complétera cet effort en permettant de créer des applications pour le bureau, le Web, le cloud, les mobiles, les jeux, l'Internet, l'intelligence artificielle et bien d'autres encore, fonctionnant sous Windows, Linux, Android, iOS, Mac/Mac Catalyst, Windows Arm64, iOS/tvOS et bien d'autres. Elle le fait en regroupant des composants autrefois disparates, dont Xamarin (d'où la fonctionnalité iOS/Android/macOS). « Un grand changement dans cette version est l'intégration complète d'Android et d'iOS dans le cadre des charges de travail existantes de Xamarin », a déclaré Lander.

« Cela nécessite la contrainte évidente d'intégrer un tas de code, de systèmes de construction et d'autres technologies. Il faut aussi intégrer les blogs, les documents et les échantillons. Nous travaillons avec l'équipe Xamarin depuis de nombreuses années, mais nous souhaitons la bienvenue à tous nos amis Xamarin dans le projet .NET 6. Nous invitons également les utilisateurs de Xamarin à faire partie de .NET 6 » a-t-il ajouté. .NET 6 Preview 1 s'attaque à plusieurs objectifs avec une série de nouvelles fonctionnalités et de grands projets, dont Blazor Desktop et une ramification du composant ASP.NET Core de Microsoft.

Cela permet le développement Wb en C# au lieu de JavaScript grâce à l'utilisation de WebAssembly. Microsoft propose désormais un étourdissant éventail d'options de développement d'applications pour le bureau, y compris WPF, WinForms, UWP, .NET MAUI, Win UI, Project Reunion, etc.

Blazor Desktop pour concevoir des applications bureau

Blazor vous permet de créer des interfaces Web interactives en utilisant C# au lieu de JavaScript. Les applications Blazor sont composées de composants d'interface utilisateur Web réutilisables mis en œuvre à l'aide de C#, HTML et CSS. Le code client et serveur est écrit en C#, ce qui permet en même temps de partager du code et des bibliothèques. Blazor est une fonctionnalité de ASP.NET, le framework de développement Web populaire qui étend la plateforme de développement .NET avec des outils et des bibliothèques pour la création d'applications Web.

Blazor s'invite désormais sur le bureau. « Nous avons d'abord pris en charge Blazor sur le serveur, puis dans le navigateur avec WebAssembly, et maintenant nous l'étendons à nouveau, pour vous permettre d'écrire des applications de bureau Blazor. Blazor Desktop vous permet de créer des applications clientes hybrides, qui combinent le Web et l'interface utilisateur native dans une application cliente native. Il est principalement destiné aux développeurs Web qui veulent offrir à leurs utilisateurs des expériences client riches et hors ligne », a écrit Lander.

Selon lui, Blazor Desktop offre un grand choix quant à la manière dont vous construisez votre application. À une extrémité du spectre des applications, vous pouvez utiliser Blazor et les technologies Web pour tous les aspects de l'expérience de l'application cliente, à l'exception du conteneur d'application natif le plus extérieur (comme la barre de titre). À l'autre extrémité du spectre, vous pouvez utiliser Blazor Desktop pour des fonctionnalités ciblées dans une application par ailleurs native (comme WPF), comme une page de profil utilisateur que vous avez déjà mise en œuvre pour votre site Web basé sur Blazor.

Tous les choix entre les deux sont également possibles. L'intéressé a ajouté qu'il est également possible d'utiliser Blazor Desktop en combinaison avec une autre pile logiciel. « Nous construisons Blazor Desktop initialement pour les applications .NET, mais il n'y a aucune raison technique pour laquelle vous ne pourriez pas l'utiliser dans une application de bureau construite avec une autre pile d'applications, par exemple Swift », a-t-il déclaré. Il explique qu'en effet, Blazor est construit sur une interface utilisateur multiplateforme pour les applications .NET.

Il s'appuie sur cette pile d'interfaces utilisateur pour un conteneur d'application et des contrôles natifs (si vous souhaitez les utiliser). « Nous construisons Blazor pour que ses performances de démarrage et de débit soient comparables à celles d'autres solutions de bureau. Pour les développeurs qui aiment Blazor et les technologies Web, nous pensons que Blazor sera un excellent choix pour la création d'applications de bureau », a-t-il ajouté.

.NET Multi-platform App UI : une extension à Xamarin

.NET Multi-platform App UI est une boîte à outils moderne qui s'appuie sur Xamarin et l'étend dans le cadre de l'unification de .NET 6. Selon Microsoft, beaucoup ont dit qu'ils souhaitaient proposer des applications belles et cohérentes sur différentes plateformes et différents appareils, et qu'ils souhaitaient partager davantage de code entre leurs applications mobiles et de bureau. Vous pourrez désormais cibler Android, iOS, macOS et Windows.

Le support multiplateforme des applications mobiles .NET 6 sera basé sur l'intégration et l'extension de la boîte à outils Xamarin.Forms, qui a été adaptée au cours des sept dernières années et, selon Microsoft, a satisfait les besoins évolutifs de nombreux clients.

Fast inner loop (Boucle intérieure rapide)

Cette phrase fait référence à ce que Lander appelle le développement itératif rapide fourni par toute plateforme de développement attrayante et productive. L'équipe de développement fait d'abord tourner la construction beaucoup plus rapidement grâce à des projets liés aux performances. Un élément notable ici est la fonctionnalité de rechargement à chaud, longtemps demandée et finalement mise en œuvre (et améliorée) par Xamarin en novembre et maintenant considérée comme une capacité générale de .NET pour C#/IL ainsi que pour XAML.

« Nous sommes en train de définir un nouveau modèle de rechargement de code à chaud que nous pouvons proposer pour tous les types d'applications. Il est probable qu'au moins une partie de cette fonctionnalité sera implémentée dans le runtime, et nous nous sommes engagés à le faire avec CoreCLR et Mono. Nous voulons permettre une construction très rapide, et des opérations encore plus rapides pour les changements de code qui peuvent sauter la construction entièrement, comme une nouvelle caractéristique standard de .NET », a fait savoir Lander.

Amélioration de la prise en charge de l'ARM64

À ce stade, Lander a annoncé que l'équipe se concentrera principalement sur l'activation fonctionnelle après avoir amélioré les performances d'Arm64 dans .NET 5.0, un effort qui sera également poursuivi.

Amélioration de la prise en charge des conteneurs

Microsoft a annoncé qu'une série de projets sont en cours pour améliorer l'expérience des conteneurs .NET, portant sur la mise à l'échelle, la réduction de la taille, l'augmentation des performances de démarrage et de débit, la prise en charge des grandes pages et bien d'autres choses encore. En ce qui concerne les nouveautés de .NET 6 Preview 1, a listé les points suivants :

• ciblage de .NET 6 : il est effectué via des surnoms de frameworks cibles (TFM - Target framework monikers), un format de jeton standardisé pour spécifier le framework cible d'une application ou d'une bibliothèque .NET qui a été utilisé pour .NET 5. Il y en a maintenant de nouveaux pour .NET 6 ;
• .NET CLI : il est plus pratique à utiliser depuis que l'équipe a adopté les bibliothèques System.CommandLine, qui ont ajouté trois fonctions principales : des "fichiers de réponse" et deux types de directives différentes ;
• bibliothèques : ici, Microsoft a ajouté de nouvelles API mathématiques à travers System.Numerics et on note également l'amélioration de la prise en charge des listes de contrôle d'accès Windows (ACL - access control lists) ;
• runtime : Microsoft a apporté pas mal de nouveaux à ce stade, mais l'une des principales caractéristiques est la prise en charge de la puce ARM64 d'Apple Silicon, qui appartient à cette société. De plus, les applications à fichier unique, qui n'étaient auparavant prises en charge que par Linux dans .NET 5, sont désormais prises en charge par Windows et macOS ;
• etc.

« .NET 6 promet d'être une nouvelle version passionnante avec de nombreuses améliorations convaincantes », a déclaré Lander dans sa conclusion. « C'est une version particulièrement intéressante, car elle contient des changements résultant de la nécessité de s'adapter à l'évolution des systèmes d'exploitation externes et de continuer à innover au sein de la plateforme .NET elle-même. C'est aussi la poursuite de l'ouverture accrue de l'équipe .NET, à la fois en termes de planification ouverte, mais aussi de partage d'outils de performance auparavant propriétaires ».

« Nous n'y sommes pas encore parvenus, mais .NET 6 sera la deuxième version de novembre consécutive, dans notre nouvelle cadence annuelle. Compte tenu du succès de l'expédition de .NET 5 en novembre 2020, dans un environnement très difficile, il y a toutes les raisons de penser que .NET 6 sera également publié à temps », a-t-il ajouté. .NET 6 a été testé avec Visual Studio 16.9 Preview 4 et Visual Studio for Mac 8.9 et Microsoft recommande d'utiliser ces versions pour essayer .NET 6. Preview 1 peut être téléchargé ici. Microsoft a également annoncé Entity Framework Core 6.0 Preview 1 et a mis en évidence les mises à jour d'ASP.NET Core dans .NET 6 Preview 1.

Source : .NET 6 Preview 1

Et vous ?

Que pensez-vous des améliorations et des nouvelles fonctionnalités ajoutées à .NET 6 Preview 1 ?

Voir aussi

Microsoft a annoncé la disponibilité générale de .NET 5 qui inclut C# 9, F# 5 et une prise en charge native de Windows Arm64

Avec .NET 5, Microsoft voudrait produire un environnement d'exécution .NET unique et une infrastructure utilisable partout

Depuis qu'il a effectué une migration vers .NET 5.0, le développeur de la bibliothèque .NET Fusion a constaté une nette amélioration des performances

.NET 5 : Benchmark.NET est dorénavant l'outil canonique pour mesurer la performance du code .NET. Voici un aperçu des améliorations de performances à venir dans .NET 5

[puffola]

Je n'ais pas encore compris leur idee pour les GUI: MAUI, Winforms, WPF, UWP, Blazor, Platform UNO

[stailer]

Je n'ais pas encore compris leur idee pour les GUI: MAUI, Winforms, WPF, UWP, Blazor, Platform UNO

Je pense que WinForms est toujours là mais bon, qui aurait l'idée de démarrer un projet là dessus ? En toute logique tu ferais du WPF.
Ce dernier est d'actualité mais là aussi, on va pas se mentir : c'est un futur WinForms, clairement l'avenir est à Blazor.

Il reste donc MAUI et UWP (car je pense pas que Platform UNO soit un outil Microsoft) que je ne connais pas ou peu. UWP fait de "l'embarqué" et de l'objet connecté alors que les autres non il me semble.

Au final sur un nouveau projet hors iot/embarqué le choix c'est juste MAUI / Blazor. Et si tu es déjà habitué au web (voir déjà sur un framework à la React ou Angular) , ben c'est "vite répondu" : Blazor est ton ami.

Evidemment il y aura une prise de risque, un pari, si tu pars sur Blazor vu la jeunesse de la techno.

[xarkam]

Je n'ais pas encore compris leur idee pour les GUI: MAUI, Winforms, WPF, UWP, Blazor, Platform UNO

Platform UNO ce n'est pas un produit géré par Microsoft.

Winforms est encore là pour ceux qui veulent ou doivent encore en faire. Des extensions pour d'anciennes version d'Office par exemple.

WPF, c'était normalement la nouvelle manière de faire des app winform. Largement plus puissant que winform.

UWP, le framework gui pour faire des apps universelle dans windows. Il y a eu des couac en cours de route. Mais on trouve pas mal d'app uwp. (surtout dans le store)

Blazor, ce n'est pas un framework gui. C'est quelque chose pour faire ce qu'on fait en react/vuejs mais totalement en C#. Tout le côté gui c'est du html/css

MAUI, c'est l'évolution de Xamarin.form vers du desktop. En gros une app faite sur windows pourra fonctionner sur macos/linux.

Il existe aussi https://avaloniaui.net/ comme gui .net multiplatforme. Rider le supporte dans sa dernière version.

[redcurve]

Je n'ais pas encore compris leur idee pour les GUI: MAUI, Winforms, WPF, UWP, Blazor, Platform UNO

Windows Forms et WPF et UWA sont du spécifique windows.

MAUI est la suite de Xamarin forms ça marche pour le mobile et le desktop sur Windows et MacOs pour le moment.

Blazor est un framework Web Assembly

[air-dex]

UWP, le framework gui pour faire des apps universelle dans windows. Il y a eu des couac en cours de route. Mais on trouve pas mal d'app uwp. (surtout dans le store)

UWP c'était quelque chose initialement prévu pour faire du "multiplateforme Windows" : Windows 10 (PC), Xbox, Windows Mobile et Hololens, sur x86 et ARM. Ça n'a pas pris car parmi toutes les plateformes Windows il n'y a vraiment que le PC x86 qui soit intéressant, donc aucun intérêt de se mettre à UWP.

Blazor, ce n'est pas un framework gui. C'est quelque chose pour faire ce qu'on fait en react/vuejs mais totalement en C#. Tout le côté gui c'est du html/css

Blazor je le vois un peu comme le nouveau Qt. La stack C++/Python-Qt-QML-JavaScript fait à peu près tout sauf du Web côté serveur, soit un petit peu moins que la stack C#-.NET-Blazor. Il y a un créneau à prendre avec Qt qui se montre de plus en plus pressant sur la version payante (et qui coûte très cher).

[redcurve]

UWP c'était quelque chose initialement prévu pour faire du "multiplateforme Windows" : Windows 10 (PC), Xbox, Windows Mobile et Hololens, sur x86 et ARM. Ça n'a pas pris car parmi toutes les plateformes Windows il n'y a vraiment que le PC x86 qui soit intéressant, donc aucun intérêt de se mettre à UWP.



Blazor je le vois un peu comme le nouveau Qt. La stack C++/Python-Qt-QML-JavaScript fait à peu près tout sauf du Web côté serveur, soit un petit peu moins que la stack C#-.NET-Blazor. Il y a un créneau à prendre avec Qt qui se montre de plus en plus pressant sur la version payante (et qui coûte très cher).

UWP ne sert pas à faire des applications graphiques, du moment qu'une application fait un truc du genre accéder au centre de notification c'est une app UWP. Les applications Legacy qui s'appuient sur Win32 vont avoir un léger problème d'ici quelques temps quand le rollout de 10X aura été effectué, avec perte de performance à la clef. Win32 a été déplacé dans un library OS, plus d'accès direct au pipeline graphique tous passe par du RDP en locale, pareil pour le système de fichier. Plus de 10 années ont été laissés pour migrer depuis le legacy OS.

[goldbergg]

UWP, c'est les application universelle dont le grand principe est qu'elle s'exécute en Sandbox et avec un système d'autorisation comme sur les smartphone.

Il est possible de faire des application graphique en XAML (mais pas le même que WPF), mais aussi des application d'arrière plan.

En théorie une application UWP est compilable en X86, X64, arm et arm64 et est compatible avec toute la chaine Win10 (PC, Xbox, IoT, etc...), mais on peut choisir de limiter les cible.

Par convention elle sont destiné a être distribué via le Store Microsoft, mais il est possible de les distribué autrement, par exemple en créant une image OEM.
Par default on ne peut pas les proposer en libre téléchargement, tel les APK sur Android, il faut activer une options dans Windows pour en installer librement en dehors du store.

Le gros problème d'UWP, c'est que comme dit en première ligne, c'est ultra bridé...

UWP a sont propre framework et n'est compatible qu'avec .net PCL/Standard, donc exit une grosse partie des package nugget.
Il est aussi impossible de faire des chose standard comme la réflexion ou manipuler des fichier n'importe comment.
Et pour finir, vue que c'est pas le même XAML que WPF, beaucoup d'élément d'interface graphique de WPF ne sont pas dispo sur UWP ou seulement de façon limité

Migrer une appli WPF vers UWP peut rapidement être un vraie casse-tête.

Dernière petite précision, si UWP vise principalement a faire des application pour le Store, toute les application du Store ne sont pas UWP, vue qu'il est possible de "convertir" une application standard en package pour le store, mais a ce moment la compatibilité devient très limité.

Plus d'info ici : https://docs.microsoft.com/fr-fr/win...platform-guide


Concernant Blazor, c'est a la base plus ou moins le remplaçant de WebForm (qui permet de dev des application web comme on le ferait en WinForm).

Le but est de créer des composant HTML réactif de la même manière qu'on le fait en Vue.js ou React, mais en C#.
Il existe malgré tous un bridge pour pouvoir exécuter du code JS depuis C# ou que le code JS invoque du code C#.

Chaque composant peut avoir des paramètre, une route pour servir de page et peuvent bien évidement s'imbriquer.

De base le Framework propose nativement des composant, notamment des élément de formulaire.

Il existe trois version :

-Serveur, ou le code s'exécute coté serveur, mais avec du code aussi coté client et une connexion SignalR (WebSocket) pour faire le lien tel que la synchro des donnée.
Couplé a Electron.Net, il est déjà possible de faire des client lourd cross-plateforme avec.

-WASM, ou la tout est coté client, mais la conception reste la même, avec toujours la possibilité d'interagir avec du JS au besoin.
Il est possible d'utiliser pas mal de lib .net directement dans le navigateur, mais avec les limitation des navigateur, donc impossible de requêter n'importe quoi en HTTP sans se prendre une erreur CORS par exemple.
Contrairement a la version serveur, on peut deployer une application WASM sur n'importe qu'elle serveur HTTP, même le plus minimaliste, tout est intégré.

-Desktop, j'ai pas encore testé, mais j'imagine que sa reprend la version WASM (donc autonome), mais sans les bridage navigateur et éventuellement avec du xml plus proche du XAML que du HTML (comme c'est le cas en react-natif par exemple)

J'invite tous le monde a tester Blazor par vous même, ça se prend en mains en quelque minute et on réalise très rapidement son énorme potentielle.

[air-dex]

En théorie une application UWP est compilable en X86, X64, arm et arm64 et est compatible avec toute la chaine Win10 (PC, Xbox, IoT, etc...), mais on peut choisir de limiter les cible.

J'insistais surtout sur le côté universel, sur le 'U' de "UWP". Sur quoi les cibles seront-elles limitées, si ce n'est Windows 10 PC ?

-Desktop, j'ai pas encore testé, mais j'imagine que sa reprend la version WASM (donc autonome), mais sans les bridage navigateur et éventuellement avec du xml plus proche du XAML que du HTML (comme c'est le cas en react-natif par exemple)

J'invite tous le monde a tester Blazor par vous même, ça se prend en mains en quelque minute et on réalise très rapidement son énorme potentielle.

Exactement comme Qt et QML donc. On aurait ainsi un backend "natif" (C++ ou Python pour Qt, C# pour Blazor), pouvant être interfacé et interagir avec un frontend fait de JavaScript et d'une interface codée dans un langage de description d'interface (QML pour Qt, XAML ou le duo HTML/CSS pour Blazor).

[redcurve]

UWP, c'est les application universelle dont le grand principe est qu'elle s'exécute en Sandbox et avec un système d'autorisation comme sur les smartphone.

Il est possible de faire des application graphique en XAML (mais pas le même que WPF), mais aussi des application d'arrière plan.

En théorie une application UWP est compilable en X86, X64, arm et arm64 et est compatible avec toute la chaine Win10 (PC, Xbox, IoT, etc...), mais on peut choisir de limiter les cible.

Par convention elle sont destiné a être distribué via le Store Microsoft, mais il est possible de les distribué autrement, par exemple en créant une image OEM.
Par default on ne peut pas les proposer en libre téléchargement, tel les APK sur Android, il faut activer une options dans Windows pour en installer librement en dehors du store.

Le gros problème d'UWP, c'est que comme dit en première ligne, c'est ultra bridé...

UWP a sont propre framework et n'est compatible qu'avec .net PCL/Standard, donc exit une grosse partie des package nugget.
Il est aussi impossible de faire des chose standard comme la réflexion ou manipuler des fichier n'importe comment.
Et pour finir, vue que c'est pas le même XAML que WPF, beaucoup d'élément d'interface graphique de WPF ne sont pas dispo sur UWP ou seulement de façon limité

Migrer une appli WPF vers UWP peut rapidement être un vraie casse-tête.

Dernière petite précision, si UWP vise principalement a faire des application pour le Store, toute les application du Store ne sont pas UWP, vue qu'il est possible de "convertir" une application standard en package pour le store, mais a ce moment la compatibilité devient très limité.

Plus d'info ici : https://docs.microsoft.com/fr-fr/win...platform-guide


Concernant Blazor, c'est a la base plus ou moins le remplaçant de WebForm (qui permet de dev des application web comme on le ferait en WinForm).

Le but est de créer des composant HTML réactif de la même manière qu'on le fait en Vue.js ou React, mais en C#.
Il existe malgré tous un bridge pour pouvoir exécuter du code JS depuis C# ou que le code JS invoque du code C#.

Chaque composant peut avoir des paramètre, une route pour servir de page et peuvent bien évidement s'imbriquer.

De base le Framework propose nativement des composant, notamment des élément de formulaire.

Il existe trois version :

-Serveur, ou le code s'exécute coté serveur, mais avec du code aussi coté client et une connexion SignalR (WebSocket) pour faire le lien tel que la synchro des donnée.
Couplé a Electron.Net, il est déjà possible de faire des client lourd cross-plateforme avec.

-WASM, ou la tout est coté client, mais la conception reste la même, avec toujours la possibilité d'interagir avec du JS au besoin.
Il est possible d'utiliser pas mal de lib .net directement dans le navigateur, mais avec les limitation des navigateur, donc impossible de requêter n'importe quoi en HTTP sans se prendre une erreur CORS par exemple.
Contrairement a la version serveur, on peut deployer une application WASM sur n'importe qu'elle serveur HTTP, même le plus minimaliste, tout est intégré.

-Desktop, j'ai pas encore testé, mais j'imagine que sa reprend la version WASM (donc autonome), mais sans les bridage navigateur et éventuellement avec du xml plus proche du XAML que du HTML (comme c'est le cas en react-natif par exemple)

J'invite tous le monde a tester Blazor par vous même, ça se prend en mains en quelque minute et on réalise très rapidement son énorme potentielle.

UWP permet à ce stade d'exploiter quasi n'importe quoi, si vous en êtes encore au stade PCL/Net standard c'est que vous avez raté la sortie du train en gare et que vous faites uniquement du legacy.

[stailer]

Merci @Goldbergg pour tous ces détails, j'aurais appris pas mal de choses sur certaines technos de .net sur lesquelles je ne suis pas.
Juste un petit truc pour chipoter :

Concernant Blazor, c'est a la base plus ou moins le remplaçant de WebForm (qui permet de dev des application web comme on le ferait en WinForm).

Pour moi le remplaçant de WebForms c'était ASP.NET MVC.

On est vraiment dans quelque chose de nouveau avec Blazor qui s'apparente à Angular (la ressemblance est plus grande qu'avec React je trouve)... Je pense que WebForms est enterré depuis longtemps. Et à mon avis, heureusement, je n'ai jamais aimé cette techno.

[youtpout978]

Le problème de Blazor c'est son premier chargement, punaise qu'est ce que c'est long, ça devrait s'améliorer avec net6.

[Stéphane le calme]

Microsoft annonce la disponibilité de .NET 6 Preview 4 qui apporte l'expérience Hot Reload
à Visual Studio et aux outils de ligne de commande

Microsoft a publié la quatrième Preview de .NET 6, successeur de .NET 5 publié en novembre dernier. .NET 6 sera lancée en novembre 2021 et représente l'aboutissement d'un effort de plusieurs années visant à fournir un framework multiplateforme à code source libre pour tout ce qui concerne .NET dans une offre globale unifiée. Dans .NET 6, l'équipe de développement se concentrera spécifiquement sur les performances des applications, l'ajout de nouveaux thèmes de contrôle et l'accélération des expériences des développeurs.

Microsoft cherche depuis quelques années maintenant à unifier et à étendre la plateforme .NET. Richard Lander, Program Manager au sein de l'équipe .NET, a expliqué que Microsoft a fait un pas vers cet objectif avec .NET Core, l'unification était censée être matérialisée avec .NET 5 avec un lancement en novembre 2020. Mais la pandémie du coronavirus ainsi que d'autres problèmes survenus au cours de l'année ont eu raison de ce calendrier.

.NET 6 va donc conduire l'éditeur à ce but en permettant de créer des applications pour desktop, le Web, le cloud, les mobiles mais aussi des jeux, des applications IdO, de l'IA et bien d'autres encore fonctionnant sous Windows, Linux, Android, iOS, Mac/Mac Catalyst, Windows Arm64, iOS/tvOS pour ne citer que ces plateformes. Pour y parvenir, .NET 6 va regrouper des composants autrefois disparates, dont Xamarin (d'où la fonctionnalité iOS/Android/macOS). « Un grand changement dans cette version est l'intégration complète d'Android et d'iOS dans le cadre des charges de travail existantes de Xamarin », a déclaré Lander.

« Cela nécessite la contrainte évidente d'intégrer un tas de code, de systèmes de construction et d'autres technologies. Il faut aussi intégrer les blogs, les documents et les échantillons. Nous travaillons avec l'équipe Xamarin depuis de nombreuses années, mais nous souhaitons la bienvenue à tous nos amis Xamarin dans le projet .NET 6. Nous invitons également les utilisateurs de Xamarin à faire partie de .NET 6 » a-t-il ajouté.

.NET 6 Preview 1 s'est attaqué à plusieurs objectifs avec une série de nouvelles fonctionnalités et de grands projets, dont Blazor Desktop et une ramification du composant ASP.NET Core de Microsoft. .NET 6 Preview 4 continue sur cette lancée.

Thèmes .NET 6

Dans un billet, Richard a expliqué :

« Nous avons commencé à planifier .NET 6 fin 2020 sur GitHub. Nous avons identifié huit thèmes à travers un large éventail de sujets, y compris les scénarios de l'industrie, le soutien et l'éducation. Les thèmes représentent de la moitié à trois quarts de nos efforts pour la sortie. Il existe de nombreux projets qui n'atteignent pas le niveau d'un thème ou qui sont significatifs mais non thématiques (comme la prise en charge des appareils Apple Silicon).

« Voici les thèmes .NET 6, chacun décrit avec un résumé d'une phrase. Ils sont répertoriés dans le même ordre qu'ils sont affichés dans themesof.net.

1. .NET attire les nouveaux développeurs et les étudiants : offre des expériences intentionnellement rationalisées dans les produits Visual Studio, avec des documents clairs, des modèles de code plus simples avec moins de fichiers et de concepts à apprendre et des chemins intuitifs pour déployer des artefacts dans des environnements de test et de production.
2. .NET a une excellente expérience de développement d'applications clientes : offre une base d'applications clientes multiplateformes qui s'adresse de manière transparente aux développeurs de bureau, mobiles et Web et qui s'appuie sur et étend les types d'applications existants tels que Blazor et Xamarin.
3. .NET est reconnu comme un framework convaincant pour la création d'applications cloud natives : offre des fonctionnalités cloud natives fondamentales principalement axées sur les performances et l'observabilité, une intégration améliorée avec les écosystèmes cloud natifs et conteneurs, et un composant cloud natif (yarp) qui démontre beaucoup de la valeur de .NET avec un cas d'utilisation critique du cloud.
4. Entreprise et LTS : fournit des modèles plus simples et plus prévisibles pour utiliser .NET avec des applications critiques et mieux répondre aux besoins des grandes entreprises et des clients gouvernementaux.
5. Développer l'écosystème .NET grâce à une qualité, une confiance et une assistance accrues : Établit une collaboration communautaire à long terme qui vise à élever les développeurs communautaires à un niveau similaire à celui de Microsoft, et (d'un autre côté) offre de nouvelles fonctionnalités et expériences qui en font plus facile pour les développeurs d'entreprise de dépendre des bibliothèques de projets open source communautaires qui ne sont pas nécessairement affiliés ou soutenus par une grande entreprise.
6. Améliorer les performances de la boucle interne pour les développeurs .NET : améliore la productivité des développeurs, notamment l'amélioration des performances de build, le redémarrage à chaud et le rechargement à chaud.
7. Améliorer le démarrage et le débit à l'aide des informations d'exécution d'exécution (PGO) : offre un nouveau modèle pour des performances améliorées basées sur des informations d'exécution qui peuvent être utilisées pour un démarrage plus rapide, un débit plus élevé et des binaires plus petits.
8. Répondre aux attentes des développeurs : apporter des améliorations à l'ensemble du produit .NET en fonction des commentaires et pour activer de nouveaux scénarios avec les fonctionnalités existantes.

Expérience Hot Reload dans le débogueur Visual Studio

Avec Hot Reload, vous pouvez désormais modifier le code source géré de vos applications pendant que l'application est en cours d'exécution, sans avoir besoin de mettre manuellement en pause ou d'atteindre un point d'arrêt. Effectuez simplement une modification prise en charge pendant l'exécution de votre application et, dans la nouvelle expérience Visual Studio, utilisez le bouton « Appliquer les modifications de code » pour appliquer vos modifications.

Hot Reload fonctionne avec de nombreux types de projets existants et à venir tels que WPF, Windows Forms, les Previewaperçus .NET MAUI, les applications ASP.NET Core code-behind, les applications console, WinUI 3 (débogueur géré requis) et bien d'autres. Cette prise en charge est très large avec l'expérience de base de tout projet alimenté par les environnements d'exécution .NET Framework ou CoreCLR.

Avec Hot Reload, l'objectif de Microsoft est de rendre cette expérience disponible quelle que soit la manière dont vous préférez lancer votre application. Avec la version d'aujourd'hui, vous pouvez désormais utiliser cette expérience via l'expérience de débogage Visual Studio entièrement intégrée ou l'outil de ligne de commande dotnet watch, avec plus d'options à venir dans les versions ultérieures.

Pour commencer à tester cette fonctionnalité, installez Visual Studio 2019 version 16.11 Preview 1 et démarrez votre application avec le débogueur Visual Studio (F5). Une fois votre application en cours d'exécution, vous disposez désormais de la nouvelle option pour apporter des modifications au code et les appliquer à l'aide du nouveau bouton « Appliquer les modifications de code », comme illustré ci-dessous.

Prise en charge de System.Text.Json pour IAsyncEnumerable

IAsyncEnumerable<T> est une fonctionnalité importante qui a été ajoutée avec .NET Core 3.0 et C# 8. Les nouvelles améliorations permettent la (dé)sérialisation System.Text.Json avec les objets IAsyncEnumerable<T>.

Les exemples suivants utilisent des flux comme représentation de toute source de données asynchrone. La source peut être des fichiers sur une machine locale ou des résultats d'une requête de base de données ou d'un appel d'API de service Web.

Sérialisation en streaming

System.Text.Json prend désormais en charge la sérialisation des valeurs IAsyncEnumerable<T> en tant que tableaux JSON, comme vous pouvez le voir dans l'exemple suivant.

Code C# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
using System;
using System.Collections.Generic;
using System.IO;
using System.Text.Json;
 
static async IAsyncEnumerable<int> PrintNumbers(int n)
{
    for (int i = 0; i < n; i++) yield return i;
}
 
using Stream stream = Console.OpenStandardOutput();
var data = new { Data = PrintNumbers(3) };
await JsonSerializer.SerializeAsync(stream, data); // prints {"Data":[0,1,2]}

Les valeurs IAsyncEnumerable sont uniquement prises en charge à l'aide des méthodes de sérialisation asynchrones. Tenter de sérialiser à l'aide des méthodes synchrones entraînera la levée d'une NotSupportedException.

Désérialisation du streaming

La désérialisation du streaming nécessitait une nouvelle API qui renvoie IAsyncEnumerable<T>. Microsoft a ajouté la méthode JsonSerializer.DeserializeAsyncEnumerable à cet effet, comme vous pouvez le voir dans l'exemple suivant.

Code C# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
using System;
using System.IO;
using System.Text;
using System.Text.Json;
 
var stream = new MemoryStream(Encoding.UTF8.GetBytes("[0,1,2,3,4]"));
await foreach (int item in JsonSerializer.DeserializeAsyncEnumerable<int>(stream))
{
    Console.WriteLine(item);
}

Cet exemple désérialise les éléments à la demande et peut être utile lors de la consommation de flux de données particulièrement volumineux. Il ne prend en charge que la lecture à partir de tableaux JSON de niveau racine, bien que cela puisse être assoupli à l'avenir en fonction des commentaires.

La méthode DeserializeAsync existante prend nominalement en charge IAsyncEnumerable<T>, mais dans les limites de sa signature de méthode non-streaming. Il doit renvoyer le résultat final sous la forme d'une valeur unique, comme vous pouvez le voir dans l'exemple suivant.

Code C# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
using System;
using System.Collections.Generic;
using System.IO;
using System.Text;
using System.Text.Json;
 
var stream = new MemoryStream(Encoding.UTF8.GetBytes(@"{""Data"":[0,1,2,3,4]}"));
var result = await JsonSerializer.DeserializeAsync<MyPoco>(stream);
await foreach (int item in result.Data)
{
    Console.WriteLine(item);
}
 
public class MyPoco
{
    public IAsyncEnumerable<int> Data { get; set; }
}

Dans cet exemple, le désérialiseur aura mis en mémoire tampon tout le contenu IAsyncEnumerable avant de renvoyer l'objet désérialisé. En effet, le désérialiseur doit avoir consommé toute la valeur JSON avant de renvoyer un résultat.

Source : Microsoft