Feuille de route pour .NET Core 2.1

L'équipe .NET a passé ces derniers mois sur GitHub à travailler sur .NET Core 2.1. De nombreux développeurs utilisent maintenant .NET Core 2.0 depuis sa publication en août dernier et souhaitent savoir quelles seront les fonctionnalités à venir. L'équipe .NET a suffisamment avancé ses travaux pour faire un tour d'horizon de cette prochaine version. Comme pour les versions précédentes, la communauté a contribué à de nombreuses améliorations.

.NET Core 2.1 est une version orientée « retour utilisateur » après une version 2.0 qui était une version plus fonctionnelle :

  • CLI : réduction des temps de compilation ;
  • CLI : outils globaux ;
  • CoreCLR : compatibilité ascendante sur version mineure ;
  • CoreCLR : pas de copie de tableau avec Span<T> ;
  • CoreFX : amélioration des performances de HttpClient ;
  • CoreFX : pack de compatibilité Windows ;
  • ASP.NET : SignalR est maintenant disponible pour .NET Core ;
  • ASP.NET : HTTPS est activée par défaut ;
  • EF : support basic du lazy loadgin ;
  • EF : support pour Azure Cosmos DB.



Réduction des temps de compilation
Les temps de compilation ont été fortement réduits avec .NET Core 2.1, particulièrement lors d'une compilation incrémentale. Les améliorations ont été faites dans les outils CLI et dans MSBuild afin de fournir une meilleure expérience, que ce soit durant les compilations en ligne de commande ou depuis Visual Studio.

Le diagramme ci-dessous montre de manière concrète les améliorations que vous pouvez espérer via cette nouvelle version. Sur le diagramme, deux cas de figure sont présentés, avec pour chacun d'entre eux les temps de compilation :
  • le temps de compilation avec .NET Core 2.0 ;
  • le temps de compilation avec une préversion de .NET Core 2.1 ;
  • l’espérance de gain avec la version finale de .NET Core 2.1.


Nom : incremental-build-core-2-1-sdk.png
Affichages : 2084
Taille : 20,4 Ko

Outils globaux .NET Core
La prochaine version de .NET Core va introduire un nouveau déploiement et un nouveau mécanisme d'extensions pour ses outils. Cette nouvelle expérience est très similaire aux outils globaux Node.js dont elle est inspirée.

Les outils .NET Core sont des applications consoles distribuées en tant que paquets NuGet. Par défaut, ces outils sont dépendants d'un framework particulier et incluent l'intégralité de leurs dépendances NuGet. Cela signifie que ces outils fonctionneront quel que soit le système d'exploitation et quelle que soit l'architecture, à partir du moment où le framework .NET Core est disponible.

Actuellement, les outils .NET Core ne supportent que les installations globales. Des travaux sont en cours pour permettre une installation locale. La syntaxe actuelle ressemble à :
Code Shell : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
   dotnet tool install -g awesome-tool
   awesome-tool

Oui, une fois un outil installé (ici, awesome-tool), vous pourrez l'utiliser directement. Vous n'aurez plus besoin de saisir dotnet awesome-tool mais juste awesome-tool.

Avec ce nouveau déploiement, un nouvel écosystème devrait voir le jour, où les outils seront déployés via des paquets NuGet. Par défaut, les paquets seront recherchés sur NuGet.org.


Span<T>, Memory<T>
De nouveaux types font leur apparition pour gérer les tableaux et la mémoire de manière plus efficace. Aujourd'hui, si on veut passer en paramètre les 1000 premiers éléments d'un tableau de 10 000 éléments, on doit passer une copie de ces 1000 éléments. Cette opération est coûteuse en temps et en mémoire. Le nouveau type Span<T> permet de fournir une « vue » d'un tableau sans les coûts associés à une copie. Et comme il s'agit d'une structure, il n'y a pas le coût lié à une allocation non plus.

Jared Parsons donne une très bonne introduction dans sa vidéo video C# 7.2: Understanding Span disponible sur Channel 9. Stephen Toub donne encore plus de détails dans un post de blog.

Span<T> et les types associés proposent une représentation unifiée de la mémoire depuis de nombreuses sources différentes, comme les tableaux, les allocations sur la pile ou la mémoire native. Avec ses possibilités de découpage, il n'est plus nécessaire de procéder à de coûteuses copies et allocations dans la plupart des scénarios. Cette nouvelle approche fournit également une alternative sûre là où, auparavant, il aurait été nécessaire d'utiliser du code unsafe.

Par exemple, pour créer un Span<T> à partir d'un tableau :

Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
var arr = new byte[10];
Span<byte> bytes = arr; // Cast implicite de T[] en Span<T>

Il est facile de créer un span pour représenter une partie d'un tableau, en utilisant une surcharge de la méthode Slice. Ensuite, les accès en lecture/écriture à partir de ce nouveau span se font de manière transparente dans la partie correspondante du tableau original :

Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
Span<byte> slicedBytes = bytes.Slice(start: 5, length: 2);
slicedBytes[0] = 42;
slicedBytes[1] = 43;
Assert.Equal(42, slicedBytes[0]);
Assert.Equal(43, slicedBytes[1]);
Assert.Equal(arr[5], slicedBytes[0]);
Assert.Equal(arr[6], slicedBytes[1]);
slicedBytes[2] = 44; // Throws IndexOutOfRangeException
bytes[2] = 45; // OK
Assert.Equal(arr[2], bytes[2]);
Assert.Equal(45, arr[2]);

Performance de HttpClient
Les requêtes sortantes représentent une part importante de la performance pour certains types d'applications, comme les microservices. .NET core 2.1 vient avec un nouveau gestionnaire HttpClient, réécrit pour de hautes performances. Un premier retour de la part de quelques bêta testeurs montre que ce nouveau gestionnaire a grandement amélioré leurs applications.

Compatibilité ascendante sur version mineure
Maintenant, il sera possible d'exécuter des applications .NET Core sur des versions plus récentes du framework tant que la version majeure reste la même. Ainsi, il sera possible d'exécuter une application .NET Core 2.0 sur le framework .NET Core 2.1 ou une application .NET Core 2.1 sur le framework .NET Core 2.5 (bien entendu, si une telle version venait à être publiée). La compatibilité ascendante est pour les versions mineures seulement, c'est-à-dire qu'il ne sera pas garanti qu'une application .NET Core 2.x puisse tourner sur une version 3.0 ou ultérieure de .NET Core.

Si la version requise de .NET Core est disponible, elle sera utilisée. La compatibilité ascendante ne sera utilisée que si la version requise de .NET Core n'est pas disponible dans un environnement donné.

Notez également qu'il sera possible de désactiver cette fonctionnalité.

Pack de compatibilité Windows
Lors du portage d'une application du framework .NET vers le framework .NET Core, vous pouvez utiliser le nouveau pack de compatibilité Windows. Il donne accès à 20 000 API supplémentaires, en plus de celles fournies via le .NET Core. Le pack inclut System.Drawing, EventLog, WMI, les compteurs de performance et les services Windows.

Si vous prévoyez de réaliser une application multiplateforme, vous pouvez utiliser un nouvel analyseur d'API pour vous assurer que vous n'utilisez pas par mégarde une API disponible uniquement pour Windows.

Disponibilité
Les préversions de .NET Core 2.1 sont prévues tous les mois à partir de ce mois, jusqu'à la publication finale qui devrait avoir lieu durant le premier semestre 2018.

Source : https://blogs.msdn.microsoft.com/dot...e-2-1-roadmap/