Les nouveautés DotNet Core 3.0 (Partie 1)

.Net Core est une version open source et multi plateforme du framework .Net. Cette version a été développée à l’origine pour s’ouvrir à d’autres OS tels que Mac OS X et Linux. Pour cela, cette nouveauté du .Net a dû abandonner toutes les technologies en lien avec Windows. Nous pensons ici à l’initiative Mono, dont l’objectif, il y a quelques années, était de porter le framework .Net 2.0 sur Linux.

Vu que .Net Core est évolutif, Microsoft peut donc y ajouter de nouvelles API et fonctionnalités , chose qu’on ne peut pas réaliser avec le framework .Net. Il faut donc s’attendre à des différences de plus en plus grandes dans le futur entre ces deux plateformes.

Pour utiliser .Net Core 3.0, il vous faudra Visual Studio 2019.

Support de Windows Forms et WPF

Grâce au composant Windows Desktop inclus dans le SDK de .Net Core 3.0, des applications de bureau WinForm (Windows Forms) et WPF (Windows Presentation Foundation) existantes peuvent s’exécuter sur Windows.

Des applications WinFom et WPF peuvent aussi être créées en .Net Core 3.0. Pour faire cela, nous devons utiliser Visual Studio 2019. Ce logiciel propose des nouveaux types de projet pour WinForm et WPF en Core 3.0. Par ailleurs, certains contrôles d’IHM (Interactions homme-machine) ont été améliorés dans cette nouvelle version.

Pour les applications WPF, le style Fluent de la bibliothèque XAML WinUI est pris en charge via les XAML islands.

Pour les applications WinForm, le mode de haute résolution peut être défini via Application.SetHighDpiMode(HighDpiMode), pour les écrans en haute résolution.

Des applications WinForm et WPF créées sous le framework .Net peuvent être migrées sous .Net Core 3.0. Cependant, comme certains contrôles utilisateurs ont évolué. Il est recommandé de tester leurs comportements à l’exécution notamment pour les contrôles Winform. Pour plus d’informations, consulter les dernières modifications de migration de .Net framework vers .Net Core 3.0.

Coexistence de plusieurs versions de .Net Core

Contrairement au framework .Net, plusieurs versions de .Net Core peuvent cohabiter sur une même machine. Cela évite les risques de compatibilité des montées de version sur les applicatifs, ceux-ci pouvant rester sur une version spécifique de .Net Core.

A noter que .Net Core peut aussi cohabiter avec une version du framework .Net sur une même machine, car son runtime est indépendant du framework .Net.

Par ailleurs, le framework .Net Core 3.0 peut être embarqué directement dans l’application. Cela évite l’installation du framework sur la machine qui héberge l’application, d’autant plus que la version embarquée peut  être différente de celle éventuellement présente sur la machine.

Prise en charge de C# 8.0

C# 8.0 est inclus dans .Net Core 3.0. La nouvelle version de C# comprend :

•   La fonctionnalité de types de référence nullable
•   Les flux asynchrones
•   Les fonctionnalités de critères spéciaux
•   Les nouveaux types System.Index et System.Range, pour l’indexation et les plages de données

.Net Standard 2.1

.Net Core 3.0 permet la création de projet de type Bibliothèque de classe en .Net Standard 2.1. Pour cela, il faut modifier le fichier .csproj pour indiquer netstandard2.1 dans le nœud TargetFramework. Par ailleurs, il est nécessaire de créer ce type de projet sous Visual Studio 2019.

Compilation d’un exécutable par défaut

Auparavant, il fallait procéder en mode déploiement autonome pour pouvoir générer un exécutable embarquant une version cible de .Net Core. Avec .Net Core 3.0 (et déjà à partir de la version .Net 2.2), il est possible de générer un exécutable qui dépend de la version cible de la version de .Net Core installée sur la machine.

Le package de déploiement est de ce fait réduit, plusieurs applications séparées pouvant cibler la même version de .Net Core.

Comme pour un exécutable natif, l’application est lançable par double clic, ou par invite de commande.

Publication d’un exécutable en mono fichier

Avec .Net Core 3.0, une application peut être publiée en 1 seul fichier auto extractible pour le déploiement. Cette archive contient toutes les dépendances nécessaires à l’exécution. Pour activer cette fonctionnalité, il faut mettre true dans le nœud PublishSingleFile du fichier de projet, ou via une invite de commande.

Liaison d’assemblies

Bien que les applications configurées en déploiement autonome incluent tous les éléments nécessaires, il arrive que l’application nécessite seulement un sous ensemble de l’infrastructure et des assemblies.

Le SDK du .Net Core 3.0 inclus l’outil Éditeur de liens de langage intermédiaire qui permet de réduire significativement la taille des applications. Il permet d’analyser le langage intermédiaire (langage IL), et en supprimer les assemblies inutilisées.

Pour utiliser cet outil, nous devons ajouter le nœud <PublishTrimmed>true</PublishTrimmed> dans le fichier de projet de l’application. Il faut faire attention à utiliser cette fonctionnalité avec discernement, car l’utilisation de la réflexion ou du mot clé dynamic dans le code peuvent provoquer un arrêt de l’application (composant introuvable).  Toutefois, l’outil peut être configuré pour ce type de scénario. Mais un test de l’application est incontournable.

Compilation hiérarchisée

La compilation hiérarchisée est activée par défaut avec .NET Core 3.0. Cette fonctionnalité permet au runtime d’utiliser de manière plus adaptative le compilateur JIT pour obtenir de meilleures performances.

Le principal avantage de la compilation hiérarchisée est d’autoriser les méthodes (re-) JIT avec un niveau de moins bonne qualité mais plus rapide, ou avec un niveau de meilleure qualité mais plus lent. Cela permet d’améliorer les performances d’une application quand elle passe par les différents stades de l’exécution, du démarrage à l’état stable. Ceci contraste avec l’approche de la compilation non hiérarchisée, où chaque méthode est compilée d’une seule manière (la même que le niveau de qualité supérieure), qui privilégie la stabilité de l’état au détriment des performances au démarrage.

Dans le fichier de projet de l’application, il est possible de désactiver cette fonctionnalité en mettant le nœud <TieredCompilation>false</TieredCompilation>.

Publication ReadyToRun

Il est possible d’améliorer le temps de démarrage d’une application .NET Core en compilant les assemblies de l’application au format ReadyToRun (R2R). R2R est une forme de compilation ahead-of-time (AOT).

Les fichiers binaires R2R améliorent les performances de démarrage en réduisant la quantité de travail que le compilateur JIT doit faire lorsque l’application est chargée. Les fichiers binaires contiennent du code natif similaire à ce que la compilation JIT produirait. Cependant, les fichiers binaires R2R sont plus grands, car ils contiennent à la fois le code du langage intermédiaire (IL), qui est toujours nécessaire pour certains scénarios, et la version native du même code.

R2R est disponible seulement pour la publication d’une application autonome qui cible des environnements d’exécution spécifiques (RID), comme Linux x64 ou Windows x64. La compilation doit se faire sur la cible d’environnement.

Pour activer le R2R, il faut mettre le nœud suivant dans le fichier de projet :

<PublishReadyToRun>true</PublishReadyToRun>

Emmanuel, Team NEXTON