.NET Core 3.0 is out
.NET Core 3.0 est publié avec un lot de nouveautés intéressantes. Support de Windows Forms + WPF, nouvelles API pour le format JSON, support de l’architecture ARM64, support de C# 8.0 + F# 4.7, et des améliorations de performance sont au menu.
Roadmap de la plateforme
La cadence des livraisons va désormais être annuelle avec une nouvelle version chaque année et une version LTS (Long Term Support) de façon bi-annuelle. Les versions LTS sont supportées à hauteur de 3 années depuis leurs dates de GA (General Availability) avec des mises à jour et correctifs. En novembre 2020 avec le .NET 5.0, on aura qu’une seule platforme .NET qui marche sur Linux, Windows et MacOS. Les versions .NET destinées à Windows uniquement recevront encore des petits correctifs et mises à jour, mais pas de nouvelles versions majeures.
Outillage
Pour travailler avec .NET Core 3.0, il est nécessaire d’avoir au moins VS 2019 16.3+/VS For Mac 8.3+/VS Code avec les extensions mises à jour. Et comme toujours, vous pouvez le télécharger pour Windows/Linux/MacOS sous forme de:
OS supportés
Alpine: 3.9+
Debian: 9+
openSUSE: 42.3+
Fedora: 26+
Ubuntu: 16.04+
RHEL: 6+
SLES: 12+
macOS: 10.13+
Windows Client: 7, 8.1, 10 (1607+)
Windows Server: 2012 R2 SP1+
Architectures supportées
- x64 sur Windows, macOS, et Linux
- x86 sur Windows
- ARM32 sur Windows et Linux
- ARM64 sur Linux (avec une version du noyau 4.14+)
WPF et Windows Forms
Aujourd’hui il est possible de migrer ses anciennes applications desktop sur Winforms vers .NET Core. Le designer Winforms est toujours en preview et utilisable en tant qu’extension VS (.vsix) séparée. Il va être ajouté prochainement à VS. Si vous utilisiez massivement le designer pour vos développements desktop, Microsoft recommande d’attendre un peu avant de porter vos applicatifs jusqu’à sa GA.
Même son de cloche côté WPF, la seule différence c’est que le designer WPF est production-ready avec XAML Hot Reload et de nouveaux templates. Techniquement le designer du .NET Core fonctionne différemment de celui du .NET classique car il exécute le code sur un nouveau processus wpfsurface.exe et la raison pour ceci est que le processus du designer classique xdesproc.exe est en lui même une application WPF classique et à cause des différences dans les runtimes .NET/.NET Core on ne peut charger les deux sur un même processus. Ceci dit, les extensions écrites pour le designer WPF auront des breaking changes.
Microsoft a fait de Winforms et WPF des projets open-source. Il manque quelques composants au projet WPF sur GitHub, mais ne vous inquiétez pas, ça viendra avec le temps .
C# 8.0
Références nullables
C’est toute une nouvelle spécification du langage C#. Et l’une des plus importante depuis un bon moment. Maintenant le compilateur C# pourra vous mettre en garde contre les NullReferenceException potentielles avec des warnings sans utiliser d’analyseur de code comme Sonar.
Les références de type nullable devront être déclarées en suffixant le nom de la classe par ? dans le code (string? name;), le compilateur dans ce cas s’attend à ce que:
Le déréférencement de la variable ne soit fait qu’après avoir vérifié que la variable n’est pas nulle.Au cas où vous avez déclaré une référence de type nullable et que vous voulez quand même la déréférencez sans vérifier la nullité, il faudra utiliser l’opérateur null-forgiving operator !.La variable est autorisée à ce qu’elle reçoit la valeur nulle.
Les références de type non-nullable devront être déclarées sans ? comme suffixe (string name;), le compilateur s’attend à ce que:
La variable ne soit jamais initialisé à nulle.
La vérification statique de nullité du compilateur C# peut être activé/désactivé par fichier/ligne à l’aide des directives pré-processeur ou par projet en utilisant la balise Nullable dans le csproj pour ne pas s’écrouler devant des tonnes de warnings lors de votre migration et permettre aux équipes d’itérer petit à petit sur le code existant afin d’enlever tout le code susceptible de causer des exceptions NullReferenceException.
Implémentation par défaut des membres d’interface
Actuellement, du moment qu’on définit une interface et qu’une centaine de classes l’implémentent, c’est finit on ne peut plus lui ajouter de nouveaux membres vu qu’il faudra les implémenter sur toute les classes fille. Avec C# 8.0 yes we can, il faudra juste donner une implémentation par défaut dans l’interface et les classes fille la recevront par défaut au cas où elles ne l’implémentent pas.
Flux asynchrones
Désormais on peut itérer de façon asynchrone sur un flux asynchrone en utilisant l’interface IAsyncEnumerable<T>. Ce qui vous permet d’awaiter le foreach. Exemple de consommation d’un flux asynchrone et de production d’un nouveau:
Nouvelles API optimisées pour le format JSON
.NET Core 3.0 inclut une nouvelle famille d’API pour le format JSON qui offrent des fonctionnalités de lecture/écriture, d’accès spécifiques via un modèle d’objet (DOM) et de sérialisation. Les nouvelles API offrent les mêmes fonctionnalités que la bibliothèque JSON.NET pour la majorité des scénarios avec plus de performance et une moindre consommation de mémoire.
Malheureusement l’abandon de JSON.NET a été une obligation pour les équipes de Microsoft et même pour l’auteur de la bibliothèque James Newton-King. Les optimisations de performance apportées notamment l’utilisation de l’encodage UTF-8 sans avoir à transcoder en UTF-16 impactaient beaucoup le code de JSON.NET. Dans cette issue GitHub, l’auteur explique toutes les raisons.
Farewell JSON.NET et merci pour tout .
SqlClient fait peau neuve
Désormais le SqlClient va être livré et utilisé à travers le nuget Microsoft.Data.SqlClient pour les deux frameworks .NET et .NET Core.
Support de HTTP/2
Le HttpClient supporte maintenant le protocole HTTP/2. A titre d’information, ce dernier est une obligation pour ceux qui travaillent avec gRPC et Apple Push Notification Service.
Support de TLS 1.3 et OpenSSL 1.1.1 pour Linux
.NET Core profite du support de SSL 1.3 par OpenSSL 1.1.1, les avantages incluent:
- Amélioration du temps de connexion à cause de la réduction du nombre d’aller-retours nécessaires entre le client et le serveur
- Plus de sécurité car les algorithmes cryptographiques désormais obsolètes ont été abandonnés et la connexion du handshake devient cryptée.
.NET Core supportera automatiquement ça sur Windows et MacOS quand les équipes OpenSSL le feront.
Support de Red Hat
Grâce au partenariat entre Microsoft avec Red Hat, .NET Core 1.0 est apparu comme composant disponible dans les collections de logiciels Red Hat, juin 2016.
Au cours des quatre dernières années, Red Hat a publié de nombreuses mises à jour et versions importantes de .NET Core, telles que les versions 2.1 et 2.2, le même jour que Microsoft. Avec .NET Core 2.2, Red Hat a étendu ses offres .NET Core aux plates-formes OpenShift. Avec la sortie de RHEL 8, .NET Core 2.1 est disponibles dans les flux d’application Red Hat et bientôt pour 3.0.
Conclusion
C’est très excitant de voir la plateforme .NET prospérer et devenir open-source, riche et diversifiée d’une livraison à une autre. A mentionner que .NET Standard 2.1, ASP.NET Core 3.0 et EF Core 3.0 ont été aussi dévoilés. Vous trouverez ce qui a été mentionné dans l’article et bien plus sur les billets suivants:
Badre BSAILA, Ingénieur d'étude et développement .NET sénior