En 2019, Microsoft a annoncé que .NET 5 serait son premier grand produit sur la voie de l'unification de .NET. C'est désormais chose faite, .NET 5 est la première version de la promesse de Microsoft d'unifier les différentes variantes de .NET à travers les systèmes d'exploitation, le Web et une variété de facteurs de forme. Il s'agit du successeur de .NET Core 3.X. Selon les explications de l'entreprise, le .NET Framework existant reste un produit Microsoft pris en charge et continuera à l'être avec chaque nouvelle version de Windows.
Ainsi, Microsoft a annoncé l'année dernière qu'il avait cessé d'ajouter de nouvelles fonctionnalités au .NET Framework à partir de la version 4.8 et avait fini d'ajouter les API du .NET Framework au .NET Core. Il ne prévoit pas non plus de publier une nouvelle version de .NET Standard. L'entreprise a annoncé cet été la fin de .NET Standard, mais elle a également précisé que .NET 5 et toutes les versions futures continueront à prendre en charge le .NET Standard 2.1 et les versions antérieures. .NET 5 fournit aux développeurs des outils, des interfaces de programmation, des fonctionnalités d'exécution et de nouveaux langages.
C'est ce que Microsoft préconise aux développeurs d'utiliser pour créer des interfaces utilisateur Web et des services de back-end. « Nous avions l'intention de réaliser l'intégralité de la vision d'unification avec .NET 5.0, mais dans le sillage de la pandémie mondiale, nous avons dû nous adapter à l'évolution des besoins de nos clients », ont déclaré les responsables dans le billet de blogue annonçant la sortie de .NET 5. Voici un aperçu des nouveautés introduites par .NET 5.
Langages
C# 9 et F# 5 font partie de .NET 5.0 et sont inclus dans le SDK de .NET 5.0. Visual Basic est également inclus dans le SDK 5.0. Il n'inclut pas de changement de langage, mais comporte des améliorations pour prendre en charge le framework d'application Visual Basic sur le noyau .NET. Les générateurs de sources C# sont une nouvelle fonctionnalité importante du compilateur C#. Ils ne font pas techniquement partie de C# 9 puisqu'il n'a pas de syntaxe de langage. Microsoft prévoit d'utiliser davantage les générateurs de sources dans le produit .NET à partir de la version 6.0 de .NET.
« Afin d'essayer la nouvelle version nous-mêmes, certains d'entre nous ont décidé de mettre à jour le dépôt dotnet/iot pour utiliser la nouvelle syntaxe C# 9 et cibler .NET 5.0. Il utilise des programmes de haut niveau, des enregistrements, des modèles et des expressions de commutation. Il a également été mis à jour pour tirer profit de l'ensemble complet des annotations annulables dans les bibliothèques .NET. Nous avons également mis à jour les documents IoT .NET », a déclaré Richard Lander de l'équipe de .NET chez Microsoft.
Améliorations de l'annotation de la nullité
Les bibliothèques .NET sont maintenant complètement annotées pour la nullité. Cela signifie que si vous activez la nullité, vous obtiendrez plus d'informations sur les types de documents de la plateforme pour orienter votre utilisation de la fonction. Actuellement, les documents .NET n'ont pas été entièrement annotés. Par exemple, String.IsNullOrEmpty(string) doit être annoté pour prendre une chaîne de caractères, tandis que String.Split(Char[]) a une annotation de char[]?. Les paquets System.Device.Gpio et Iot.Device.Bindings (version 1.1.0 pour les deux) ont aussi été annotés dans le cadre de cette version, en utilisant les annotations .NET 5.0 mises à jour.
L'équipe a également ajouté de nouveaux types d'annotations. En effet, il est courant pour les grandes classes d'instancier les propriétés d'un objet dans des méthodes d'aide appelées par un constructeur. Le compilateur C# ne peut pas suivre le flux des appels à l'affectation des objets. Il pensera que le membre est nul lorsqu'il sortira du constructeur et avertira avec CS8618. L'attribut MemberNotNull résout ce problème. Vous appliquez l'attribut à la méthode helper. Le compilateur verra alors que vous avez défini cette valeur et réalisera que la méthode est appelée depuis un constructeur. L'attribut MemberNotNullWhen est similaire.
Améliorations apportées aux outils
L'équipe a amélioré le concepteur de formulaires Windows, modifié le fonctionnement des frameworks cibles pour .NET 5.0 et au-delà, modifié la prise en charge de WinRT et apporté d'autres améliorations. Tout d'abord, le concepteur de formulaires Windows (pour .NET Core 3.1 et .NET 5.0) a été mis à jour dans Visual Studio 16.8, et prend désormais en charge tous les contrôles de formulaires Windows. Il prend également en charge l'interface utilisateur de Telerik pour les contrôles WinForms.
Le concepteur comprend toutes les fonctionnalités de conception auxquelles vous pouvez vous attendre, notamment : glisser-déposer, sélection, déplacement et redimensionnement, couper/copier/coller/supprimer, intégration avec "Properties Window", génération d'événements et plus encore. La liaison des données et la prise en charge d'un ensemble plus large de contrôles tiers sont prévues prochainement. En seconde position, l'équipe a modifié l'approche qu'elle utilise pour les frameworks cibles avec .NET 5.0.
Elle a déclaré que le nouveau formulaire net5.0 est plus compact et plus intuitif que le style netcoreapp3.1 qu'elle a utilisé jusqu'à présent. En outre, elle étend le framework cible pour décrire les dépendances du système d'exploitation. Ce changement est motivé par la vision de l'équipe de permettre le ciblage d'iOS et d'Android avec Xamarin dans .NET 6.0. Les API de bureau Windows, y compris les formulaires Windows, WPF et WinRT, ne seront disponibles que pour le ciblage de net5.0-windows. Vous pouvez spécifier une version de système d'exploitation, comme net5.0-windows7 ou net5.0-windows10.0.17763.0.
Vous devez cibler une version de Windows 10 si vous voulez utiliser les API WinRT. Les scénarios multiplateformes peuvent être un peu plus difficiles, lorsque vous utilisez le nouveau TFM net5.0-windows. System.Device.Gpio présente un modèle de gestion du target-framework de Windows si vous voulez éviter de construire pour Windows ou de tirer des paquets d'exécution Windows sur Linux, par exemple. En résumé :
- net5.0 est le nouveau Target Framework Moniker (TFM) pour .NET 5.0 ;
- net5.0 combine et remplace les TFM netcoreapp et netstandard ;
- net5.0 prend en charge le mode de compatibilité du .NET Framework ;
- net5.0 sera utilisé pour exposer les fonctionnalités spécifiques à Windows, notamment les formulaires Windows, les API WPF et WinRT ;
- NET 6.0 utilisera la même approche, avec net6.0, et ajoutera net6.0-ios et net6.0-android;
- les TFM spécifiques au système d'exploitation peuvent inclure des numéros de version du système d'exploitation, comme net6.0-ios14 ;
- les API portables, comme ASP.NET Core, seront utilisables avec net5.0. Il en sera de même pour les formulaires Xamarin avec net6.0 ;
Les modèles de Visual Studio 16.8 ciblent toujours le .NET Core 3.1, pour les applications de console, WPF et Windows Forms. Les modèles ASP.NET ont été mis à jour pour prendre en charge .NET 5.0. Dans le cas de WinRT, l'équipe a annoncé que des changements de ruptures sont intervenus. En ce qui concerne le ciblage des API Windows, elle est passée à un nouveau modèle de prise en charge des API WinRT dans le cadre de .NET 5.0.
Cela comprend l'appel des API (dans les deux sens ; CLR <==> WinRT), le rassemblement des données entre les deux systèmes de types et l'unification des types qui sont destinés à être traités de la même manière à travers la limite du système de types ou de l'ABI.
Débogage des dumps
Le débogage de code géré nécessite la connaissance des objets et des constructions gérés. Le composant d'accès aux données (DAC) est un sous-ensemble du moteur d'exécution qui a la connaissance de ces constructions et peut accéder à ces objets gérés sans temps d'exécution. Les dumps de processus .NET Core collectés sur Linux peuvent maintenant être analysés sur Windows à l'aide de WinDBG ou de dotnet dump analyze. L'équipe a également ajouté la prise en charge de la capture des dumps ELF des processus .NET exécutés sous macOS.
Comme ELF n'est pas le format de fichier exécutable natif (les débogueurs natifs comme lldb ne fonctionneront pas avec ces dumps) sous macOS, elle en a fait une fonction d'inclusion. Pour activer la prise en charge de la collecte des dumps sous macOS, définissez la variable d'environnement COMPlus_DbgEnableElfDumpOnMacOS=1. Les dumps résultants peuvent être analysés en utilisant l'analyse de dump dotnet. Par ailleurs, il y a eu de nombreuses améliorations dans le runtime et les bibliothèques.
Améliorations de la qualité du code dans RyuJIT
Il y a eu beaucoup d'améliorations dans le JIT de cette version, dont beaucoup ont été partagées dans les précédents messages de prévisualisation du .NET 5.0. Dans le message de mardi, Lander a cité quelques changements apportés par la communauté, dont :
- changement pour le code de mise à zéro du prologue x86/x64 ;
- la classe BitArray a été mise à jour pour inclure une implémentation accélérée par le matériel pour Arm64 utilisant les intrinsèques de Arm64 ;
- certaines (peut-être la plupart) utilisations de génériques ont maintenant de meilleures performances, basées sur l'amélioration de l'implémentation de dictionnaires de bas niveau (code natif) utilisés par le runtime pour stocker des informations sur les types et méthodes génériques ;
- ajout des intrinsèques VectorTableList et TableVectorExtension ;
- amélioration des performances de l'architecture Intel grâce à de nouvelles caractéristiques matérielles BSF/BSR ;
- etc.
Améliorations apportées au garbage collector
Les améliorations suivantes ont été apportées au GC :
- le serveur GC (sur différents threads) peut maintenant fonctionner en mode vol tout en marquant les objets gen0/1 tenus en direct par les objets de l'ancienne génération. Cela signifie que les pauses du GC sont plus courtes pour les scénarios où certains threads du GC ont pris beaucoup plus de temps à marquer que d'autres ;
- ajout de Pinned Object Heap (POH). Ce nouveau tas (un homologue de Large Object Heap (LOH)) permettra au GC de gérer les objets épinglés séparément, et par conséquent d'éviter les effets négatifs des objets épinglés sur les tas générationnels ;
- activation de l'allocation des LOH à partir de la liste libre pendant que le BGC balaye le SOH. Auparavant, cela n'utilisait que l'espace de fin de segment sur LOH. Cela permettait une meilleure utilisation du tas ;
- corrections de la suspension pour réduire le temps de suspension des threads BGC et utilisateur. Cela réduit le temps total nécessaire à la suspension des threads gérés avant qu'un GC puisse avoir lieu. dotnet/coreclr contribue également au même résultat ;
- ajout du support pour lire les limites des groupes nommés ;
- prise en charge de l'analyse générationnelle qui vous permet de déterminer ce que les objets de l'ancienne génération retiennent aux objets de la nouvelle génération, les faisant ainsi survivre et contribuer au temps de pause du GC ;
- etc.
Windows Arm64
Les applications .NET peuvent désormais s'exécuter en mode natif sur Windows Arm64. Cela fait suite au support que l'équipe a ajouté pour Linux Arm64 (support pour glibc et musl) avec le .NET Core 3.0. Avec .NET 5.0, vous pouvez développer et exécuter des applications sur des périphériques Windows Arm64, tels que Surface Pro X. Vous pouvez déjà exécuter des applications .NET Core et .NET Framework sur Windows Arm64, mais via une émulation x86. C'est faisable, mais l'exécution native d'Arm64 offre de bien meilleures performances.
Performance d'Arm64
L'équipe a déclaré qu'elle s'est investie de manière significative dans l'amélioration des performances de l'Arm64, depuis plus d'un an. « Nous nous sommes engagés à faire d'Arm64 une plateforme haute performance avec .NET. Ces améliorations s'appliquent aussi bien à Windows qu'à Linux. La portabilité et la cohérence de la plateforme ont toujours été des caractéristiques incontournables de .NET. Cela inclut l'offre d'une grande performance partout où vous utilisez .NET. Avec .NET Core 3.x, Arm64 a la même fonctionnalité que x64, mais il lui manque certaines caractéristiques de performance et certains investissements clés. Nous avons résolu ce problème dans .NET 5.0 », a déclaré Lander. Les améliorations apportées ici sont :
- ajuster les optimisations JIT pour Arm64 ;
- activer et tirer parti des caractéristiques intrinsèques du matériel Arm64 ;
- ajuster les algorithmes critiques de performance dans les bibliothèques pour Arm64.
Plateforme et support Microsoft
NET 5.0 a une matrice de support de plateforme presque identique à celle de NET Core 3.1, pour Windows, macOS et Linux. Si vous utilisez .NET Core 3.1 sur un système d'exploitation pris en charge, vous devriez pouvoir adopter .NET 5.0 sur cette même version de système d'exploitation pour la plupart. L'ajout le plus important pour .NET 5.0 est Windows Arm64. NET 5.0 est une version actuelle. Cela signifie qu'il sera pris en charge pendant trois mois après la sortie de .NET 6.0. Par conséquent, l'équipe prévoit de prendre en charge .NET 5.0 jusqu'à la mi-février 2022. NET 6.0 sera une version LTS et sera prise en charge pendant trois ans, tout comme NET Core 3.1.
Source : Microsoft
Et vous ?
Qu'en pensez-vous ?
Voir aussi
La deuxième version admissible de .NET 5.0 est disponible et constitue la dernière RC avant la sortie de la version stable en novembre, Microsoft autorise son utilisation en production
Microsoft annonce la fin de .NET Standard, sa couche de base unique pour toutes les applications .NET, y compris Xamarin. Il sera remplacé par .NET 5
.NET 5.0 Preview 8 est estampillée comme "feature complete" et apporte de nombreuses fonctionnalités ainsi que le support de Windows ARM64 et Web Assemby