Discussion :

[Stéphane le calme]

Microsoft annonce la disponibilité de .NET 5 Preview 1 qui apporte des améliorations des performances d'expressions régulières,
ainsi que des améliorations de la qualité du code dans RyuJIT

À la fin de l'année dernière, Microsoft a livré .NET Core 3.0 et 3.1. Ces versions ont ajouté les modèles d'applications de bureau Windows Forms (WinForms) et WPF, ASP.NET Blazor pour la création d'applications à page unique et gRPC pour la messagerie multiplateforme basée sur des contrats. Microsoft a également ajouté des modèles pour la création de services, une riche génération de code client pour parler à gRPC, des services d'API REST et bien plus encore. .NET Core 3 est devenu la version la plus rapide jamais adoptée de .NET et l’outil a gagné un autre million d'utilisateurs supplémentaires au cours de la dernière année seulement.

Microsoft a annoncé la disponibilité de la première préversion de .NET 5, mais n’a pas manqué de rappeler certains éléments au préalable :

« Alors que nous attendons avec impatience la prochaine version majeure, .NET 5, nous continuerons à unifier .NET en une seule plateforme en incluant notre modèle d'application pour appareil mobile .NET (Xamarin) dans .NET 5. .NET 5 inclura ASP.NET Core, Entity Framework Core, WinForms, WPF, Xamarin et ML.NET. Pour la première fois, la plateforme entière utilisera un BCL (Base Class Library) unifié pour tous les modèles d'application. Avoir une version 5 supérieure à .NET Core et .NET Framework montre également clairement que .NET 5 est l'avenir de .NET, qui est une plateforme unifiée unique pour la construction de tout type d'application.

« Nous l'avons dit à maintes reprises, mais nous le réitérons; .NET Core puis .NET 5 est le .NET avec lequel vous devez créer toutes vos NOUVELLES applications. .NET Framework restera pris en charge tant que Windows lui-même est pris en charge. Nous continuerons de fournir des correctifs de sécurité et de bogues et de mettre à jour les API de mise en réseau et de chiffrement. Il restera sécurisé et pris en charge pour conserver vos anciennes applications sur .NET Framework ».

Microsoft a présenté certains des objectifs de haut niveau pour .NET 5 :

• Expérience du SDK .NET unifié :
  
  • BCL (Base Class Library) unique dans toutes les applications .NET 5. Aujourd'hui, les applications Xamarin utilisent le Mono BCL, mais vont utiliser le .NET Core BCL, améliorant la compatibilité entre nos modèles d'application.
  • Le développement mobile (Xamarin) est intégré dans .NET 5. Cela signifie que le SDK .NET prend en charge les mobiles. Par exemple, vous pouvez utiliser « dotnet new XamarinForms » pour créer une application mobile.
• Native Applications prenant en charge plusieurs plateformes : projet Single Device prenant en charge une application pouvant fonctionner sur plusieurs appareils, par exemple Windows Desktop, Microsoft Duo (Android) et iOS à l'aide des contrôles natifs pris en charge sur ces plateformes.
• Web Applications prenant en charge plusieurs plateformes: projet Single Blazor qui prend en charge une application pouvant fonctionner dans les navigateurs, sur les appareils mobiles et en tant qu'application de bureau native (Windows 10x par exemple)
• Cloud Native Applications: hautes performances, fichier unique (.exe) <50 Mo de microservices et prise en charge de la création de plusieurs projets (API, web front end, conteneurs) à la fois localement et dans le cloud.
• Améliorations continues, telles que: algorithmes plus rapides dans la BCL, meilleure prise en charge des conteneurs lors de l'exécution, prise en charge de HTTP3.

Microsoft reconnait que la première préversion qui est proposée ne contient pas encore tout le travail nécessaire pour atteindre ces objectifs de haut niveau, mais l’éditeur assure qu’il va continuer d'annoncer davantage de capacités et de fonctionnalités dans les préversions futures.

Améliorations apportées par la Preview 1

Améliorations des performances d'expression régulière

Microsoft a investi dans des améliorations significatives du moteur Regex : « sur de nombreuses expressions que nous avons essayées, ces améliorations entraînent régulièrement des améliorations de débit de 3 à 6 fois, et dans certains cas, bien plus encore. Nous publierons prochainement un article de blog qui décrira ces améliorations de manière beaucoup plus détaillée ».

Améliorations de la qualité du code dans RyuJIT

Chaque version inclut un ensemble d'améliorations des performances du code généré par le JIT. Microsoft appelle ce type d'améliorations «CQ» ou code quality (qualité du code). Dans la plupart des cas, ces améliorations s'appliquent également au code généré pour les images prêtes à fonctionner.

Les améliorations suivantes sont dans la préversion 1 :

• Améliorations pour le pliage des contrôles null : supprime la nécessité de générer des contrôles de null dans plus de cas en observant plus de modèles où les contrôles null sont manifestement inutiles.
• Ajustement des common subexpression evaluation (CSE)  : Le JIT recherche et réduit les expressions en double qui n'ont besoin d'être évaluées qu'une seule fois.
• Optimisation de “constant_string”.Length : optimisation de ce modèle et réduction du code à la valeur entière correcte.
• JIT: construction des listes de prédiction de bloc de base avant le morphing : réorganise les phases dans le JIT pour permettre l'utilisation des optimisations clés plus tôt, résultant en une meilleure qualité de code et moins de travail pour les phases suivantes, ce qui augmente le débit JIT.

Diagnostics de la charge de l'assemblage ajoutés au pipeline d'évènement

Microsoft a ajouté des informations sur la charge de l'assemblage au pipeline d'évènements. Cette amélioration est le début de la mise à disposition de fonctionnalités de diagnostic similaires, comme cela fait partie de .NET Framework avec Fusion Log Viewer. Vous pouvez maintenant utiliser dotnet-trace pour collecter ces informations, à l'aide de la commande suivante:

Code C# :

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

dotnet-trace collect --providers Microsoft-Windows-DotNETRuntime:4:4 --process-id [process ID]

Vous pouvez voir les informations de chargement d'assemblage pour une application de test simple.

API profileur pipeline d'évènement

Le pipeline d'évènement est un nouveau sous-système et une nouvelle API que Microsoft a ajoutée dans .NET Core 2.2 pour permettre d'effectuer des performances et d'autres investigations de diagnostic sur n'importe quel système d'exploitation. Dans .NET 5.0, le pipeline d'évènement a été étendu pour permettre aux profileurs d'écrire des évènements sur le pipeline d'évènement. Ce scénario est critique pour l'instrumentation des profileurs qui s'appuyaient auparavant sur ETW pour surveiller le comportement et les performances des applications.

Consolidation du référentiel GitHub

Dans le cadre de la version .NET 5, Microsoft a réduit le nombre de dépôts GitHub qu'il utilise pour créer et empaqueter .NET. Les limites du référentiel ont un impact significatif sur de nombreux aspects d'un projet, y compris les builds et la gestion des problèmes. « Avec .NET Core 1.0, nous avions plus de 100 référentiels sur ASP.NET, EF et .NET Core. Avec cette dernière version, nous pouvons désormais compter les dépôts principaux d'une part. Nous avons également déplacé presque tous les référentiels vers l'organisation dotnet ».

Preview 1 inclut la prise en charge de Windows ARM64 pour la première fois. La version d'aujourd'hui inclut le runtime .NET Core. Microsoft prévoit que la Preview 2 inclue le SDK (ASP.NET Core mais pas WPF ou Windows Forms). Une préversion ultérieure inclura WPF et Windows Forms. La prise en charge de Windows ARM64 sera également rétroportée vers .NET Core 3.1.

La disponibilité générale de .NET 5 est prévue pour novembre de l'année en cours.

.NET 5.0 Preview 1 SDK
.NET 5.0 Preview 1 Runtime

Source : Microsoft

[Stéphane le calme]

.NET 5.0 Preview 7 est disponible et s'accompagne d'améliorations au niveau de la récupération mémoire,
ainsi que de nouvelles fonctionnalités

Microsoft a annoncé la disponibilité de .NET 5.0 Preview 7, l'avant-dernière des versions Preview (avant de passer à RC). La plupart des fonctionnalités devraient être proches de leur version stable à ce stade.

Récupération de mémoire (garbage collection - GC)

Le récupérateur de mémoire affiche maintenant des informations détaillées sur la récupération la plus récente, via la méthode GC.GetGCMemoryInfo, qui retourne une structure GCMemoryInfo. GCMemoryInfo fournit des informations sur la mémoire de la machine, la mémoire de tas (allocation dynamique) et la récupération la plus récente ou alors la récupération la plus récente du type de GC que vous spécifiez.

Les cas d'utilisation les plus probables de l'emploi de cette nouvelle API sont la journalisation / le monitoring ou pour indiquer à un équilibreur de chargeur qu'une machine doit être retirée de la rotation pour demander un GC complet. Elle pourrait également être utilisée pour éviter les limites strictes des conteneurs en réduisant la taille des caches.

Un autre changement, mineur, mais important, a été apporté pour reporter l'opération coûteuse de réinitialisation de la mémoire aux situations de mémoire insuffisante. Microsoft s'attend à ce que ces changements de politique réduisent la latence du GC (et l'utilisation du CPU du GC en général).

System.Text.Json

Microsoft a ajouté une fonctionnalité à la nouvelle API JSON. Les fonctionnalités suivantes sont nouvelles dans Preview 7 (et d'autres devraient venir dans la Preview 8) :

• [Breaking change] Possibilité d'ignorer les valeurs par défaut des propriétés de type valeur lors de la sérialisation - peut être utilisée pour réduire les coûts de sérialisation.
• Capacité à gérer les références circulaires lors de la sérialisation - la forme de l'API devrait maintenant être définitive.

RyuJIT

RyuJIT est le générateur de code d'assemblage pour .NET qui cible à la fois les puces Intel et ARM. La plupart des investissements dans RyuJIT sont axés sur la performance.

• Améliorations générales
  
  • Possibilité d'activer l'élimination de certaines vérifications de limites
  • Optimisation de Enum.CompareTo après avoir été réécrit en C# - les performances sont désormais à parité avec l'implémentation C++ précédente.
  • Amélioration de l'allocation des registres pour les structs
  • Améliorations de la suppression des initialisations zéro redondantes
  • Amélioration de la duplication de la queue
  • Correctif CQ de copie de structures basées sur la pile
  • Nettoie une affectation de champ mort après avoir supprimé les initialisations de zéro redondantes
• ARM64
  
  • Mise en œuvre de la majorité des éléments intrinsèques « par élément »
  • Implémentation de fcvtxn, fcvtxn2, sqabs, sqneg, suqadd, usqadd intrinsèques
  • Optimisation de SpanHelpers.IndexOf(byte), SpanHelpers.IndexOf(char)
  • Optimisation de SpanHelpers.IndexOfAny(byte)
  • Optimisation de WithLower, WithUpper, Create, AsInt64, AsUInt64, AsDouble
  • Optimisation de AsVector, AsVector128, GetUpper, As and WithElement

Rappelons certains des objectifs de haut niveau pour .NET 5 :

• Expérience du SDK .NET unifié :
  
  • BCL (Base Class Library) unique dans toutes les applications .NET 5. Aujourd'hui, les applications Xamarin utilisent le Mono BCL, mais vont utiliser le .NET Core BCL, améliorant la compatibilité entre nos modèles d'application.
  • Le développement mobile (Xamarin) est intégré dans .NET 5. Cela signifie que le SDK .NET prend en charge les mobiles. Par exemple, vous pouvez utiliser « dotnet new XamarinForms » pour créer une application mobile.
• Native Applications prenant en charge plusieurs plateformes : projet Single Device prenant en charge une application pouvant fonctionner sur plusieurs appareils, par exemple Windows Desktop, Microsoft Duo (Android) et iOS à l'aide des contrôles natifs pris en charge sur ces plateformes.
• Web Applications prenant en charge plusieurs plateformes: projet Single Blazor qui prend en charge une application pouvant fonctionner dans les navigateurs, sur les appareils mobiles et en tant qu'application de bureau native (Windows 10x par exemple)
• Cloud Native Applications: hautes performances, fichier unique (.exe) <50 Mo de microservices et prise en charge de la création de plusieurs projets (API, web front end, conteneurs) à la fois localement et dans le cloud.
• Améliorations continues, telles que: algorithmes plus rapides dans la BCL, meilleure prise en charge des conteneurs lors de l'exécution, prise en charge de HTTP3.

Dans sa Preview 4, .NET 5 a apporté :

• Des améliorations du compilateur RyuJIT JIT : qui comportent une nouvelle implémentation, beaucoup plus rapide et portable, des assistants tailcall ; la poursuite des progrès de la mise en œuvre du matériel ARM64 ; l’amélioration de la vitesse du JIT dans un cas qui affectait la compilation d'expressions régulières ; l’amélioration des performances de l'architecture Intel grâce à de nouvelles caractéristiques matérielles BSF/BSR et l'implémentation de Vector{Size}.AllBitsSet.
• Les exportations natives (exportations pour les binaires natifs qui font appel au code .NET) : Microsoft a activé cette fonctionnalité à la demande des développeurs. La composante de base de cette fonctionnalité est l'hébergement de l'API pour l'attribut UnmanagedCallersOnlyAttribute.
• La suppression du support WinRT intégré dans .NET 5.0 (une annonce anticipée pour la Preview 6) : les avantages de ce changement sont : WinRT interop peut être développé et amélioré séparément du runtime .NET ; la suppression rend WinRT interop symétrique avec les systèmes interop fournis pour d'autres systèmes d'exploitation, comme iOS et Android, d’après l’équipe .Net ; elle peut également tirer parti de nombreuses autres fonctionnalités de .NET (AOT, fonctionnalités C#, liaison IL) et simplifier la base de code du runtime .NET.
• Extension du System.DirectoryServices.Protocols à Linux et MacOS : System.DirectoryServices.Protocols est une API de niveau inférieur à System.DirectoryServices, et permet (ou peut être utilisé pour permettre) un plus grand nombre de scénarios. Les deux ensembles d'API permettent de contrôler un serveur de services d'annuaire, comme LDAP ou Active Directory, et d'interagir avec lui. L’équipe .NET a ajouté un support multiplateforme pour les protocoles System.DirectoryServices.Protocols. Dans la Preview 5, la prise en charge de Linux a été ajoutée et la prise en charge de MacOS sera ajoutée dans la Preview 6. La prise en charge de Windows était préexistante.
• Support d'Alpine Linux 3.12 : Microsoft a ajouté, cette semaine, la prise en charge d'Alpine 3.12 (sorti en le 29 mai), de .NET Core 3.1 et de .NET 5. L’équipe continue de travailler sur l'ajout de la prise en charge des nouvelles versions de distribution de Linux.

Télécharger .NET 5.0 Preview 7 (Windows, macOS, Linux)

Source : Microsoft

[gstratege]

Je comprend pas trop l'idée derrière .Net 5, au lieu d'avoir .Net Core et .Net Framework séparés, on les réunis, mais comment ? juste on les mets côtes à côtes dans un même package ?

[Pol63]

.net 5 est surtout un .net core 4, qui inclut la clr de xamarin et celle de .net framework
les apps windows sont encore en package séparés (mais inclus) comme sur .net core 3
mais les framework (qui ne sont qu'un ensemble de classes codées en c#) contiennent des pans entiers identiques (même si certaines choses de .net 4.8 ne seront pas dans .net 5 car déclarées obsolètes)

le but devant être entre autre de faire comprendre avec le 5 que c'est la version la plus récente au dessus du fx 4.8 parce que .net core et .net framework sont actuellement sur une branche chacun.
et ceux qui sont sur .net core suivent donc sauront que .net 5 est la suite de .net core 3.1 (alors que ceux qui sont sur 4.8 ne sont peut etre pas au fait concernant .net core et seront peut etre tenté de migré et seront forcés de se renseigner)

[redcurve]

Je comprend pas trop l'idée derrière .Net 5, au lieu d'avoir .Net Core et .Net Framework séparés, on les réunis, mais comment ? juste on les mets côtes à côtes dans un même package ?

Hein .Net Framework est figé depuis l'an dernier MS fait juste des patch de sécu dessus


.NET5 prend la suite de .Net Core (le Core dans le nom était la juste pour éviter la confusion avec .Net Framework 1,2,3,4)

[Stéphane le calme]

.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

Microsoft a indiqué : « Aujourd'hui, nous publions .NET 5.0 Preview 8. La version .NET 5.0 est désormais estampillée "feature complete", ce qui signifie que presque toutes les fonctionnalités sont dans leur forme finale (à l'exception des corrections de bogues à venir). La Preview 8 est, à juste titre, la dernière Preview. Nous prévoyons de publier deux Release Candidate avant la version finale de .NET 5.0 en novembre. »

.NET 5.0 inclut de nombreuses améliorations, notamment des applications à fichier unique, des images de conteneur plus petites, des API JsonSerializer plus performantes, un ensemble complet d'annotations de type référence Nullable et la prise en charge de Windows ARM64. Les performances ont été considérablement améliorées, dans les bibliothèques NET, dans le GC et le JIT. ARM64 était un objectif clé pour l'investissement dans les performances, ce qui se traduisait par un meilleur débit et des binaires plus petits. .NET 5.0 inclut de nouvelles versions de langage, notamment C# 9 et F# 5.0.

.NET 5.0 inclut également la prise en charge de Web Assembly, à l'aide du runtime Mono et des bibliothèques .NET. C'est la base de Blazor Web Assembly dans .NET 5.0. Il s'agit d'un changement par rapport à Blazor 3.2, qui utilisait le runtime Mono et les bibliothèques Mono. L'année dernière, Microsoft a présenté une vision d'une plateforme .NET unifiée, avec un ensemble de bibliothèques et d'outils pour tous les types d'applications .NET. Les avantages de ce changement sont une expérience de développement unique pour .NET, une compatibilité beaucoup plus élevée entre les différents types d'applications .NET et la maintenance et l'amélioration d'une seule base de code.

Maintenant que la version est feature complete, passons en revue quelques nouveautés de .NET 5.0.

Langages

C# 9 et F# 5 font partie de la version .NET 5.0 et sont inclus dans le SDK .NET 5.0. Visual Basic est également inclus dans le SDK 5.0. Il n'inclut pas les modifications de langage, mais a des améliorations pour prendre en charge le Visual Basic Application Framework sur .NET Core.

Les générateurs de sources C# sont une nouvelle fonctionnalité importante du compilateur C# qui ne fait pas techniquement partie de C# 9 car il n'a pas de syntaxe de langage.

C# 9

C# 9 est une version importante du langage, axée sur la simplicité du programme, l'immuabilité des données et plus de modèles. Voici quelques éléments que les développeurs pourraient trouver intéressants.

Programmes de haut niveau

Les programmes de haut niveau offrent une syntaxe plus simple pour les programmes, avec beaucoup moins de cérémonie. Cette syntaxe aidera les gens à apprendre le langage en premier lieu. L'éditeur s'attend à ce que la syntaxe du programme de haut niveau devienne plus simple dans les versions ultérieures, comme la suppression des instructions using par défaut.

Voici la version C# 9 de « hello world ».

Code C# :

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

1
2
3
using System;
 
Console.WriteLine("Hello World!");

Les programmes de haut niveau peuvent être étendus pour utiliser plus de fonctionnalités, telles que la définition et l'appel d'une méthode ou d'une classe dans le même fichier.

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
18
19
20
21
22
23
24
25
26
using System;
using System.Runtime.InteropServices;
 
Console.WriteLine("Hello World!");
FromWhom();
Show.Excitement("Top-level programs can be brief, and can grow as slowly or quickly in complexity as you'd like", 8);
 
void FromWhom()
{
    Console.WriteLine($"From {RuntimeInformation.FrameworkDescription}");
}
 
internal class Show
{
    internal static void Excitement(string message, int levelOf)
    {
        Console.Write(message);
 
        for (int i = 0; i < levelOf; i++)
        {
            Console.Write("!");
        }
 
        Console.WriteLine();
    }
}

Ce programme produit la sortie suivante :

[rich@taumarunui test]$ ~/dotnet/dotnet run
Hello World!
From .NET 5.0.0-preview.8
Top-level programs can be brief, and can grow as slowly or quickly in complexity as you'd like!!!!!!!!

Pattern matching

Il s'agit ici de procéder à des tests pour voir si une valeur a une certaine forme et d'extraire des informations de la valeur lorsqu'elle a la forme correspondante. De nouvelles améliorations de pattern matching ont été ajoutées dans les dernières versions de C#.

Voici deux exemples : le premier montre l'utilisation des propriétés dans le pattern matching. Il vérifie la valeur null (avec is) avant de comparer context de l'objet à un modèle (pattern) spécifique.

Code C# :

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

1
2
3
4
if (context is {IsReachable: true, Length: > 1 })
{
    Console.WriteLine(context.Name);
}

Ce qui est équivalent à :

Code C# :

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

1
2
3
4
if (context is object && context.IsReachable && context.Length > 1 )
{
    Console.WriteLine(context.Name);
}

Mais est aussi équivalent à :

Code C# :

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

1
2
3
4
if (context?.IsReachable && context?.Length > 1 )
{
    Console.WriteLine(context.Name);
}

L'exemple suivant utilise des modèles relationnels (comme <, <=) et logiques (comme and, or et not). Le code suivant produit le péage routier (sous forme décimale) pour un camion de livraison en fonction de son poids brut. Pour ceux qui ne sont pas familiers, m après un littéral numérique indique au compilateur que le nombre est sous forme de decimal et non double.

Code C# :

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

1
2
3
4
5
6
DeliveryTruck t when t.GrossWeightClass switch
{
    < 3000 => 8.00m,
    >= 3000 and <= 5000 => 10.00m,
    > 5000 => 15.00m,
},

F# 5

S'appuyant sur les mises à jour de la Preview F# 5 publiées plus tôt cette année, cette dernière mise à jour de F# 5 conclut la prise en charge des langages et ajoute deux nouvelles fonctionnalités, les chaînes interpolées et les déclarations de type ouvert. Voici un aperçu de ce que vous pouvez en faire:

Chaînes interpolées

Les chaînes interpolées en F# sont l'une des fonctionnalités les plus demandées. Les gens qui les connaissent en C# et JavaScript (et peut-être dans d'autres langages) en sont venus à les aimer dans ces langages. En F#, l'éditeur présente des chaînes interpolées de manière non typée comme elles existent dans d'autres langages, mais également avec des trous interpolés typés où l'expression dans un contexte interpolé doit correspondre à un type donné par un spécificateur de format de chaîne.

Code F# :

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

1
2
3
4
5
6
7
8
9
// Basic interpolated string
let name = "Phillip"
let age = 29
let message = $"Name: {name}, Age: {age}"
 
// Typed interpolation
// '%s' requires the interpolation to be of type string
// '%d' requires the interpolation to be an integer
let message2 = $"Name: %s{name}, Age: %d{age}"

Déclarations de type ouvert

Les déclarations de type ouvert en F# sont similaires à la possibilité d'ouvrir des classes statiques en C#, mais avec une syntaxe légèrement différente. Elles sont également étendues pour permettre l'ouverture de types spécifiques à F#.

Code F# :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
open type System.Math
 
let x = Min(1.0, 2.0)
 
module M =
    type DU = A | B | C
 
    let someOtherFunction x = x + 1
 
// Open only the type inside the module
open type M.DU
 
printfn "%A" A

Outils de diagnostic d'exécution

Microsoft.Extensions.Logging

Microsoft a amélioré le fournisseur de journaux de la console dans la bibliothèque Microsoft.Extensions.Logging. Les développeurs peuvent désormais implémenter un ConsoleFormatter personnalisé pour exercer un contrôle complet sur le formatage et la colorisation de la sortie de la console. Les API du formateur permettent un formatage riche en implémentant un sous-ensemble des séquences d'échappement du VT-100 (pris en charge par la plupart des terminaux modernes). L'enregistreur de console peut analyser les séquences d'échappement sur des terminaux non pris en charge, ce qui vous permet de créer un formateur unique pour tous les terminaux.

En plus de la prise en charge des formateurs personnalisés, Microsoft a également ajouté un formateur JSON intégré qui émet des journaux JSON structurés vers la console.

Débogage dump

Le débogage du code managé nécessite une connaissance particulière des objets gérés et des constructions. Le composant d'accès aux données (DAC - Data Access Component) est un sous-ensemble du moteur d'exécution de runtime qui connaît ces constructions et peut accéder à ces objets gérés sans exécution. Depuis la Preview 8, Microsoft a commencé à compiler le DAC Linux sur Windows. Les vidages de processus .NET Core collectés sous Linux peuvent désormais être analysés sous Windows à l'aide de WinDBG ou dotnet dump analyze..

Technologie runtime

De nombreuses nouvelles fonctionnalités ont été ajoutées dans .NET 5.0. Une petite sélection est décrite ci-dessous.

Windows ARM64

Microsoft a ajouté la prise en charge de Windows ARM64 dans le cadre de cette version. L'éditeur a pris la décision relativement tardive de retarder le composant Windows Desktop (Windows Forms, WPF). Windows Forms est presque prêt, mais WPF ne l'est pas, et Microsoft ne veut pas publier seulement la moitié du composant Windows Desktop, en partie parce que les tests ne sont pas effectués dans une configuration fractionnée.

Exportations natives

Vous pouvez désormais exporter des méthodes gérées vers du code natif. Le bloc de construction de la fonctionnalité héberge la prise en charge de l'API pour UnmanagedCallersOnlyAttribute.

Télécharger .NET 5.0 Preview 8

Source : Microsoft

[Stéphane le calme]

.NET 5 ajoutera la prise en charge des nombres à virgule flottante 16 bits
avec le type Half

La spécification IEEE 754 définit de nombreux types à virgule flottante, notamment: binary16, binary32, binary64 et binary128. La plupart des développeurs sont des habitués de binary32 (équivalent à float en C#) et binary64 (équivalent à double en C#). Ils fournissent un format standard pour représenter une large gamme de valeurs avec une précision acceptable pour de nombreuses applications. .NET a toujours eu float et double et avec .NET 5 Preview 7, Microsoft a ajouté un nouveau type Half (équivalent à binary16)!

Half est un nombre binaire à virgule flottante qui occupe donc 16 bits (deux octets). Avec la moitié du nombre de bits en virgule flottante, Half peut représenter des valeurs dans la plage ±65504. Plus formellement, le type Half est défini comme un format d'échange 16 bits de base 2 destiné à prendre en charge l'échange de données en virgule flottante entre les implémentations. L'un des principaux cas d'utilisation du type Half est d'économiser de l'espace de stockage où le résultat calculé n'a pas besoin d'être stocké avec une précision totale. De nombreuses charges de travail de calcul profitent déjà du type Half : le machine learning, les cartes graphiques, les derniers processeurs, les bibliothèques SIMD natives, etc.

Les 16 bits du type Half sont divisés en:

• Bit de signe (bit dans une représentation de nombres signés qui indique le signe d’un nombre): 1 bit.
• Bits d'exposants: 5 bits.
• Bits significatifs: 10 bits (avec 1 bit implicite non stocké).

Malgré le fait que les bits significatifs comportent 10 bits, Prashanth Govindarajan de l'équipe .NET explique que la précision totale est en réalité de 11 bits. Le format est supposé avoir un bit de tête implicite de valeur 1 (sauf si le champ d'exposant est composé entièrement de zéros, auquel cas le bit de tête a la valeur 0). Pour représenter le nombre 1 au format Half, nous utiliserons les bits:

0 01111 0000000000 = 1

Le bit de tête (notre bit de signe) est 0, indiquant un nombre positif. Les bits d'exposant sont 01111, ou 15 en décimal. Cependant, les bits d'exposant ne représentent pas directement l'exposant. Au lieu de cela, un biais d'exposant est défini qui permet au format de représenter à la fois des exposants positifs et négatifs. Pour le type Half, ce biais d'exposant est 15. Le vrai exposant est dérivé en soustrayant 15 de l'exposant stocké. Par conséquent, 01111 représente l'exposant e = 01111 (en binaire) - 15 (le biais de l'exposant) = 0. Le bit significatif est 0000000000, qui peut être interprété comme le nombre .bit_significatif(en base 2) en base 2, soit 0 dans notre cas . Si, par exemple, le bit significatif était 0000011010 (26 en décimal), on peut diviser sa valeur décimale 26 par le nombre de valeurs représentables en 10 bits (1 << 10): donc le bit significatif 0000011010 (en binaire) est 26 / ( 1 << 10) = 26/1024 = 0,025390625 en décimal. Enfin, comme nos bits d'exposant stockés (01111) ne sont pas tous à 0, nous avons un bit de tête implicite de 1. Par conséquent :

0 01111 0000000000 = 2^0 * (1 + 2^0) = 1

En général, les 16 bits d'une valeur Half sont interprétés comme -1 ^ (bit de signe) * 2 ^ (exposant stocké - 15) * (bit implicit + (bit significatif / 1024)). Un cas particulier existe pour l'exposant stocké 00000. Dans ce cas, les bits sont interprétés comme -1 ^ (bit de signe) * 2 ^ (- 14) * (0 + (bit significatif / 1024)). Examinons les représentations binaires de certains autres nombres au format Half:

Plus petite valeur positive non nulle

0 00000 0000000001 = -1^(0) * 2^(-14) * (0 + 1/1024) ≈ 0.000000059604645

(Notez que le bit implicite est 0 ici, car les bits des exposants stockés sont tous 0)

Le plus grand nombre normal

0 11110 1111111111 = -1^(0) * 2^(15) * (1 + 1023/1024) ≈ 65504

Infini négatif

1 11111 0000000000 = -Infinité

Une particularité du format est qu'il définit à la fois 0 positif et négatif:

1 00000 0000000000 = -0

0 00000 0000000000 = +0

Conversions vers / de float / double

Un Half peut être converti en / à partir d'un float / double en le lançant simplement:

Code :

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

float f = (float)half; Half h = (Half)floatValue;

Toute valeur Half, étant donné que Half utilise seulement 16 bits, peut être représentée sous la forme d'un float/double sans perte de précision. Cependant, l'inverse n'est pas vrai. Une certaine précision peut être perdue lors du passage de float/double à Half. Dans .NET 5.0, le type Half est principalement un type d'échange sans opérateur arithmétique défini dessus. Il ne prend en charge que les opérateurs d'analyse, de formatage et de comparaison. Toutes les opérations arithmétiques nécessiteront une conversion explicite en float/double. Les versions futures envisageront d'ajouter des opérateurs arithmétiques directement sur Half.

L'un des points que Microsoft considère est la possibilité ou non d'ajouter la prise en charge de Half sur un langage comme C# à l'avenir. La prise en charge au niveau du langage permettrait un identifiant tel que f16 (similaire au f qui existe aujourd'hui) et des conversions implicites / explicites. Ainsi, le type Half défini par la bibliothèque doit être défini d'une manière qui n'entraîne aucun changement de rupture si Half venait à être implémenté. Plus précisément, l'éditeur estime devoir faire attention lors de l'ajout des opérateurs au type Half. Les conversions implicites en float / double pourraient conduire à des changements de rupture potentiels si la prise en charge du langage était ajoutée.

Source : Microsoft

[CaptainDangeax]

Je ne vois pas trop l'intérêt de la chose. dotNet ne tourne qu'en environnement windows, donc sur nos PC windows. Et nos PC sont 32/64 bits, c'est à dire qu'un registre du processeur sera toujours en 32 bits. Un LD ou un MOV en assembleur se fera sur un registre en 32 bits. Sur un microcontrolleur où la place est limitée, je vois bien l'intéret de la chose, pour avoir un peu plus de précision avec 16 bits... Mais sur un PC / Windows, non vraiment je ne vois pas.

[redcurve]

Je ne vois pas trop l'intérêt de la chose. dotNet ne tourne qu'en environnement windows, donc sur nos PC windows. Et nos PC sont 32/64 bits, c'est à dire qu'un registre du processeur sera toujours en 32 bits. Un LD ou un MOV en assembleur se fera sur un registre en 32 bits. Sur un microcontrolleur où la place est limitée, je vois bien l'intéret de la chose, pour avoir un peu plus de précision avec 16 bits... Mais sur un PC / Windows, non vraiment je ne vois pas.

Toi t'as rien capté depuis 10 ans

[Captain Spic]

Je ne vois pas trop l'intérêt de la chose. dotNet ne tourne qu'en environnement windows, donc sur nos PC windows. Et nos PC sont 32/64 bits, c'est à dire qu'un registre du processeur sera toujours en 32 bits. Un LD ou un MOV en assembleur se fera sur un registre en 32 bits. Sur un microcontrolleur où la place est limitée, je vois bien l'intéret de la chose, pour avoir un peu plus de précision avec 16 bits... Mais sur un PC / Windows, non vraiment je ne vois pas.

Même si le programme tourne en 32 ou 64 bits, et utilisera ces 32 ou 64 bits par cycle, en RAM, les valeurs sont stockées par lots de 8 bits (un octet).
On divise par deux l'espace nécessaire.
Pour un programme classique, je ne suis pas sûr que l'impact soit significatif.
Mais pour un programme qui manipule beaucoup de données de ce genre (Big Data, BDD, etc) ça peut faire beaucoup d'économie :

• Pour un million d'entrée, on gagne 16 Mo
• Pour un milliard, on gagne 16 Go !

Voilà pourquoi c'est intéressant

P.S. Sinon .NET est cross-plateforme depuis maintenant un certain temps (d'abord Roslyn, Xamarin, puis .Net Core et enfin .NET 5 qui va fusionner .Net Core et .Net Framework)

[CaptainDangeax]

Jamais vu de dotNet sur un µcontrolleur. C'est C + ASM.


Prends un programme compilé et regarde les instructions MOV ou LD : elles sont toutes en 32 bits. Alors si c'est pour charger 2 fois 16 bits puis faire un SWAP pour accéder à l'autre mot, non je ne vois pas l'intérêt. Mais bon je parle à des développeurs dotNet, pas à des développeurs C ou ASM.

[redcurve]

Prends un programme compilé et regarde les instructions MOV ou LD : elles sont toutes en 32 bits. Alors si c'est pour charger 2 fois 16 bits puis faire un SWAP pour accéder à l'autre mot, non je ne vois pas l'intérêt. Mais bon je parle à des développeurs dotNet, pas à des développeurs C ou ASM.

Toujours à coté de la plaque

Top pour nos programmes de machine learning

[CaptainDangeax]

Toujours à coté de la plaque

Top pour nos programmes de machine learning

C'est bien ce petit ton moqueur depuis le début. Et sinon, c'est quand la dernière fois que tu as pondu un programme en ASM ?

[LinxBe]

C'est bien ce petit ton moqueur depuis le début. Et sinon, c'est quand la dernière fois que tu as pondu un programme en ASM ?

Pourquoi parlez-vous de ASM ?
Il ne s'agit pas d'un problème de programmation, mais de STOCKAGE !

[Kropernic]

C'est bien beau de fusionner tout ça mais quid des types spatiaux ?

Aux dernières nouvelles, ils ne sont toujours pas supporté par .Net Core. Enfin il y a bien un moyen détourner en utilisant Net Topology Suite mais pour avoir tester cette librairie, je ne suis pas convaincu du tout...

Est-ce que cette fusion .Net Fx et .Net Core fera qu'on pourra utiliser la librairie Microsoft.SqlServer.Types (SqlServerSpatial140.dll) ?

[Bill Fassinou]

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 a publié ce mardi la deuxième version candidate de .NET 5.0 et a expliqué qu’il s’agit d’une version “go live”, c’est-à-dire qu’il est possible de l’utiliser en production. Cette version du framework corrige les bogues de la RC1 et introduit également quelques nouvelles fonctionnalités, dont la correspondance de modèles en C# 9, l’option de déploiement ClickOnce et d’autres. Selon la feuille de route de Microsoft, c’est la dernière RC avant la sortie de la version stable de .NET 5.0 le mois prochain.

NET 5.0 comprend plusieurs améliorations, dont des applications à fichier unique, des images de conteneurs plus petites, des API JsonSerializer plus performantes, etc., un ensemble complet d'annotations de type référence Nullable et la prise en charge de Windows ARM64. Les performances ont été considérablement améliorées, dans les bibliothèques .NET, dans le GC et le JIT. Selon Microsoft, ARM64 est l’un des éléments clés qui ont motivé l’investissement dans les performances. Cela a permis d'améliorer de façon considérable le débit et de réduire les binaires. Voici quelques améliorations intervenues dans .NET 5.0 RC 2.

C# 9 Pattern Matching

Le Pattern matching est une fonctionnalité linguistique qui a été ajoutée pour la première fois dans C# 7.0. En effet, C# 7.0 a introduit la notion de modèle, qui sont, dans l'abstrait, des éléments syntaxiques permettant de procéder à des tests afin de voir si une valeur a une certaine “forme”, et d'extraire des informations de la valeur lorsqu'elle en a une. L'équipe C# a ajouté de nouveaux modèles dans chacune des versions C# 7, C# 8 et C# 9. Voici les trois nouveaux modèles introduits dans C# 9.

les modèles relationnels, utilisant des opérateurs relationnels tels que "<" et ">=" ;
les modèles logiques, utilisant les mots clés “and”, “or”, et “not”. Ce type de modèle est particulièrement utile lorsque vous souhaitez comparer plusieurs choses dans un même modèle ;
les modèles de type simple, utilisant uniquement un type et aucune autre syntaxe pour la comparaison.

ClickOnce

ClickOnce est une option de déploiement .NET très populaire disponible depuis .NET Framework 2.0. Il permet une distribution facile et une mise à jour automatique des applications Windows via des serveurs Web et des lecteurs réseau. L'installation est possible sans droits d'administrateur et a lieu dans le répertoire local de l'utilisateur. Selon Microsoft, ClickOnce est désormais pris en charge pour les applications Windows .NET Core 3.1 et .NET 5.0. De même, ClickOnce est également désormais disponible à la fois en ligne de commande et dans Visual Studio.

Microsoft a déclaré que le principal modèle de déploiement que ClickOnce prend actuellement en charge est celui des applications dépendantes du framework. Votre installateur ClickOnce installera le runtime .NET sur les machines des utilisateurs si nécessaire. L'entreprise a aussi l'intention de prendre en charge les applications autonomes et à fichier unique. Vous pouvez en outre profiter des fonctionnalités de ClickOnce même en étant hors ligne. Par ailleurs, avec .NET 5.0, Microsoft a également introduit des changements pour Mage.

Le grand changement avec Mage dans .NET 5.0 est qu'il est maintenant un outil .NET, distribué sur NuGet. Cela signifie que vous n'avez pas besoin d'installer quoi que ce soit de spécial sur votre machine. Vous avez juste besoin du SDK .NET 5.0 et vous pouvez ensuite installer Mage comme un outil .NET. Vous pouvez également l'utiliser pour publier des applications .NET Framework, mais la signature SHA1 et le support de confiance partiel ont été supprimés.

Windows Arm64

Les installateurs MSI sont maintenant disponibles pour Windows Arm64. Le SDK .NET 5.0 ne contient pas actuellement les composants du bureau Windows : Windows Forms et WPF. « Nous espérons ajouter le Windows Desktop Pack pour Windows Arm64 dans une mise à jour de maintenance. Nous n'avons pas de date à partager pour l’instant. Mais pour le moment, le SDK, la console et les applications ASP.NET Core sont pris en charge par Windows Arm64 », a précisé Richard Lander de l’équipe .NET.

Enfin, Microsoft considère cette deuxième version candidate comme une version “go live”, ce qui veut dire que vous pouvez l’utiliser en production, sans attendre forcément la publication de la version stable en novembre. D’ailleurs, Lander a annoncé que le site officiel de .NET fonctionne sous .NET 5.0 depuis l'aperçu 1 et fonctionne maintenant sous la RC 2.

Source : .NET 5.0 RC 2

Et vous ?

Qu'en pensez-vous ?

Voir aussi

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

.NET 5.0 Preview 5 est disponible, avec un "petit" ensemble de nouvelles fonctionnalités et d'améliorations des performances, dont des changements apportés au compilateur RyuJIT JIT et autres

.NET 5.0 Preview 7 est disponible et s'accompagne d'améliorations au niveau de la récupération mémoire, ainsi que de nouvelles fonctionnalités

[Bill Fassinou]

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

À l'occasion du premier jour de l'événement virtuel ".NET Conf 2020" ce mardi, Microsoft a annoncé la disponibilité de la version stable de .NET 5. Cette version comprend C# 9, F# 5, et la version correspondante du noyau ASP.NET. Elle fournit également une prise en charge native de Windows Arm64, ainsi que des améliorations de performance dans les bibliothèques .NET et dans le garbage collector, des images de conteneurs plus petites et des applications à fichier unique.

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

[JackIsJack]

Très content que cette série ".net Core" se termine...

[Stéphane le calme]

Depuis qu'il a effectué une migration vers .NET 5.0, le développeur de la bibliothèque Fusion a constaté une nette amélioration des performances
« attendez-vous à une augmentation de la vitesse de + 20% dans les applications "normales" »

La semaine dernière, à l'occasion du premier jour de l'événement ".NET Conf 2020" qui s’est tenu en ligne, Microsoft a annoncé la disponibilité de la version stable de .NET 5. Cette version comprend C# 9, F# 5, et la version correspondante du noyau ASP.NET. Elle fournit également une prise en charge native de Windows Arm64, ainsi que des améliorations de performance dans les bibliothèques .NET et dans le garbage collector, des images de conteneurs plus petites et des applications à fichier unique.

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 formats de dispositifs. 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.

À la même période, Microsoft a indiqué qu'il avait cessé d'ajouter de nouvelles fonctionnalités au .NET Framework dès 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.

Notons qu’EF Core (Entity Framework Core) 5 a été publié en même temps que .NET 5.0. Les premières versions d'EF Core se sont concentrées sur la création d'une architecture flexible et extensible. Dans EF Core 3.1, l'équipe a mis au point cette architecture avec quelques modifications majeures et un pipeline de requêtes remanié. La fondation de 3.1 a permis à l'équipe et à la communauté de fournir un ensemble étonnant de nouvelles fonctionnalités pour EF Core 5.0 parmi lesquelles :

• Mappage des relations plusieurs-à-plusieurs
• Mappage d'héritage table par type
• IndexAttribute pour mapper des index sans l'API fluent
• Classements de base de données
• La méthode Include prend désormais en charge le filtrage des entités incluses
• La journalisation simple
• La possibilité d’exclure des tables des migrations
• La possibilité de fractionner les requêtes pour les collections associées
• Les compteurs d'événements
• EF Core 5.0 introduit à la fois les événements .NET et un intercepteur EF Core déclenché lorsque SaveChanges est appelé.
• Des scripts de migrations avec transactions
• La reconstruction des tables SQLite selon les besoins dans les migrations
• Le mappage pour les Table-valued functions (TVF, des fonctions définies par l'utilisateur qui renvoie des données de type table)
• Prise en charge de DbContextFactory pour l'injection de dépendances
• ChangeTracker.Clear pour arrêter le suivi de toutes les entités
• Amélioration de la configuration Cosmos
• Proxy de suivi des modifications

Des améliorations notables de performance ?

Certains développeurs font déjà mention des gains de performance. C’est le cas du développeur Alex Yakunin derrière la bibliothèque .NET Fusion qui a effectué la migration vers .NET 5 et a déclaré « honnêtement, j'ai été absolument étonné par le gain de performances qu'il apporte ».

Voici comment est présentée la bibliothèque Fusion sur GitHub :

« Fusion est une bibliothèque .NET 5 / .NET Core 3.1 fournissant une nouvelle abstraction de suivi des modifications basée sur l'hypothèse que chaque élément de données que vous avez fait partie de l'état / modèle observable, et puisqu'il n'y a aucun moyen de s'adapter à un état aussi énorme en RAM, Fusion:

• Génère la partie observée de cet état à la demande
• Conserve le graphique de dépendance de tout état observé en mémoire pour s'assurer que chaque dépendance de cet état déclenche une invalidation en cascade une fois qu'elle est modifiée.
• Et enfin, il fait tout cela automatiquement et de manière transparente pour vous, de sorte que le code basé sur Fusion est presque identique au code que vous écririez sans lui.

« C'est assez similaire à ce que fait n'importe quel moteur de jeu MMORPG: même si l'état complet du jeu est énorme, il est toujours possible d'exécuter le jeu en temps réel pour plus de 1M joueurs, car chaque joueur observe une infime fraction d'un état de jeu complet, et donc tout ce dont vous avez besoin est de vous assurer que cette partie de l'état tient dans la RAM. En plus, vous avez suffisamment de puissance de calcul pour traiter les changements d'état pour chaque joueur ».

Dans son billet, il a fourni deux captures d’écrans de sorties (output) produites par un échantillon "Catching" de Fusion qui utilise EF Core (Entity Framework Core) 5 et ASP.NET Core.

« La vitesse des tests produisant plus de 20 millions d’opérations / s (# 1, # 3) est principalement limitée par la logique de Fusion et Castle.DynamicProxy. Et les tests produisant environ 100 000 opérations / s sont limités par EF et SQL Server (# 2, # 5) ou ASP.NET Core (# 4 - c'est ~ la même chose que # 5, mais en s'appuyant sur les fonctionnalités de mise en cache de Fusion). Tout cela signifie que:

• Vous pouvez vous attendre à une augmentation de la vitesse de + 20% dans les applications « normales ».
• Et cela peut aller jusqu'à + 100 %, si nous parlons de points de terminaison API ASP.NET Core relativement rapides (ceux qui dépendent fortement des caches, etc.). »

S'il a prévu de faire plus de tests par la suite et d'en partager les résultats, il a tenu à féliciter l'équipe derrière le développement de .NET : « il est clair, même maintenant, que l'équipe .NET a livré plus que ce à quoi je pouvais m'attendre - félicitations et un immense merci à tous ceux qui ont rendu cela possible ! »

Pour ceux qui auraient besoin de plus d'évaluations sur l'amélioration des performances apportée par .NET 5.0, il les a dirigés vers un billet technique rédigé par Stephen Toub en juillet (.NET 5.0 était donc encore en Preview).

Sources : billet Alex Yakunin, EF Core 5.0

Et vous ?

Avez-vous effectué la migration vers .NET 5.0 ? Quels changements avez-vous rencontrés (difficultés, améliorations des performances, etc.) ?
Que pensez-vous des propos du développeur de la bibliothèque Fusion ?

[Gugelhupf]

Je suis en train de regarder cette série de benchmarks Java (OpenJDK 15) vs C# (.NET 5) et je dois bien avouer que C# a prit les devants sur Java concernant le temps d'exécution et la consommation mémoire.