Nouveautés de .NET Core 2.1

  • Article

.NET Core 2.1 inclut les nouvelles fonctionnalités et améliorations dans les domaines suivants :

Outillage

Le Kit SDK.NET Core 2.1 (2.1.300), les outils inclus avec .NET Core 2.1, intègrent les modifications et améliorations suivantes :

Amélioration des performances des builds

Un objectif majeur de .NET Core 2.1 est l’amélioration des performances des builds, en particulier pour les builds incrémentielles. Ces améliorations des performances s’appliquent aux builds en ligne de commande à l’aide de dotnet build et aux builds dans Visual Studio. Certaines zones individuelles d’amélioration incluent :

  • Pour la résolution de ressources de package, résolution uniquement des ressources utilisées par une build plutôt que de toutes les ressources.

  • Mise en cache des références d’assembly.

  • Utilisation de serveurs de build SDK de longue durée, représentant des processus qui couvrent des appels dotnet build individuels. Ils suppriment la nécessité de la compilation JIT de grands blocs de code à chaque exécution de dotnet build. Les processus d’un serveur de build peuvent être automatiquement terminés avec la commande suivante :

    dotnet buildserver shutdown

Nouvelles commandes CLI

Un certain nombre d’outils qui étaient disponibles uniquement par projet à l’aide de DotnetCliToolReference sont désormais disponibles dans le cadre du Kit de développement .NET Core. Ces outils incluent :

  • dotnet watch fournit un observateur de système de fichiers qui attend la modification d’un fichier avant d’exécuter un ensemble désigné de commandes. Par exemple, la commande suivante reconstruit automatiquement le projet actuel et génère une sortie détaillée à chaque modification d’un fichier :

    dotnet watch -- --verbose build

    Remarquez l’option -- qui précède l’option --verbose. Elle délimite les options passées directement à la commande dotnet watch à partir des arguments passés au processus enfant dotnet. Sans elle, l’option --verbose s’applique à la commande dotnet watch, et non à la commande dotnet build.

    Pour plus d’informations, consultez Développer des applications ASP.NET Core à l’aide de dotnet watch.

  • dotnet dev-certs génère et gère les certificats utilisés pendant le développement dans les applications ASP.NET Core.

  • dotnet user-secrets gère les secrets d’un magasin de secrets d’un utilisateur dans les applications ASP.NET Core.

  • dotnet sql-cache crée un tableau et des index dans une base de données Microsoft SQL Server à utiliser pour la mise en cache distribuée.

  • dotnet ef est un outil de gestion des bases de données, des objets DbContext et des migrations dans les applications Entity Framework Core. Pour plus d’informations, consultez Outils en ligne de commande EF Core .NET.

Outils globaux

.NET Core 2.1 prend en charge les outils globaux, autrement dit des outils personnalisés disponibles globalement à partir de la ligne de commande. Le modèle d’extensibilité des versions précédentes de .NET Core proposant des outils personnalisés par projet uniquement à l’aide de DotnetCliToolReference.

Pour installer un outil global, vous utilisez la commande dotnet tool install. Par exemple :

dotnet tool install -g dotnetsay

Une fois installé, l’outil peut être exécuté à partir de la ligne de commande en spécifiant le nom de l’outil. Pour plus d’informations, consultez Vue d’ensemble des outils globaux .NET Core.

Gestion des outils avec la commande dotnet tool

Dans le SDK .NET Core 2.1, toutes les opérations avec les outils utilisent la commande dotnet tool. Les options suivantes sont disponibles :

Restauration par progression

Toutes les applications .NET Core depuis .NET Core 2.0 extrapolent automatiquement vers la dernière version mineure installée sur un système.

À compter de .NET Core 2.0, si la version de .NET Core avec laquelle une application a été créée n’est pas présente lors de l’exécution, l’application s’exécute automatiquement avec la dernière version mineure installée de .NET Core. En d’autres termes, si une application est générée avec .NET Core 2.0 et que .NET Core 2.0 n’est pas présent sur le système hôte, mais que .NET Core 2.1 l’est, l’application s’exécute avec .NET Core 2.1.

Important

Ce comportement de restauration par progression ne s’applique pas aux préversions, Par défaut, il ne s’applique pas non plus aux versions majeures, mais vous pouvez changer ce comportement avec les paramètres ci-dessous.

Vous pouvez modifier ce comportement en changeant le paramètre d’extrapolation en cas d’absence de framework partagé candidat. Les paramètres disponibles sont :

  • 0 : désactiver le comportement d’extrapolation de version mineure. Avec ce paramètre, une application conçue pour .NET Core 2.0.0 extrapole vers .NET Core 2.0.1, mais pas vers .NET Core 2.2.0 ou .NET Core 3.0.0.
  • 1 : activer le comportement d’extrapolation de version mineure. Il s’agit de la valeur par défaut pour ce paramètre. Avec ce paramètre, une application conçue pour .NET Core 2.0.0 extrapole vers .NET Core 2.0.1 ou .NET Core 2.2.0 (en fonction de la version installée), mais n’extrapole pas vers .NET Core 3.0.0.
  • 2 : activer le comportement d’extrapolation de version mineure et majeure. Si cette option est définie, même les versions majeures différentes sont prises en compte. Ainsi, une application conçue pour .NET Core 2.0.0 extrapole vers .NET Core 3.0.0.

Vous pouvez modifier ce paramètre de trois manières :

  • Affectez à la variable d’environnement DOTNET_ROLL_FORWARD_ON_NO_CANDIDATE_FX la valeur souhaitée.

  • Ajoutez la ligne suivante avec la valeur souhaitée au fichier .runtimeconfig.json :

    "rollForwardOnNoCandidateFx" : 0

  • Quand vous utilisez l’interface CLI .NET, ajoutez l’option suivante avec la valeur souhaitée à une commande .NET telle que run :

    dotnet run --rollForwardOnNoCandidateFx=0

L’extrapolation de version de correctif logiciel est indépendante de ce paramètre, et est effectuée une fois que l’éventuelle extrapolation de version mineure ou majeure a été appliquée.

Déploiement

Maintenance d’une application autonome

dotnet publish publie désormais des applications autonomes avec une version de runtime révisée. Lorsque vous publiez une application autonome avec le Kit de développement .NET Core 2.1 (2.1.300), votre application inclut la dernière version du runtime révisée et identifiée par ce SDK. Lorsque vous effectuez une mise à niveau vers la dernière version du Kit de développement logiciel (SDK), vous publiez la dernière version runtime de .NET Core. Cela s’applique aux runtimes .NET Core 1.0 et versions ultérieures.

La publication autonome s’appuie sur les versions runtime sur NuGet.org. Vous n’avez pas besoin d’avoir le runtime pris en charge sur votre ordinateur.

À l’aide du Kit de développement logiciel .NET Core 2.0, les applications autonomes sont publiées avec le runtime .NET Core 2.0.0, sauf si une version différente est spécifiée via la propriété RuntimeFrameworkVersion. Avec ce nouveau comportement, vous n’aurez plus besoin de définir cette propriété afin de sélectionner une version runtime ultérieure pour une application autonome. Dorénavant, l’approche la plus simple consiste à toujours publier avec le Kit de développement .NET Core 2.1 (2.1.300).

Pour plus d’informations, voir Restauration par progression du runtime de déploiement autonome.

Pack de compatibilité Windows

Lorsque vous portez du code existant de .NET Framework vers .NET Core, vous pouvez utiliser le pack de compatibilité Windows. Il permet d’accéder aux plus de 20 000 API disponibles dans .NET Core. Ces API incluent les types dans l’espace de noms System.Drawing, la classe EventLog, WMI, les compteurs de performances, les services Windows, ainsi que les types et membres de registre Windows.

Améliorations du compilateur JIT

.NET Core intègre une nouvelle technologie de compilateur JIT appelée compilation à plusieurs niveaux (ou également optimisation adaptative), qui peut améliorer considérablement les performances. La compilation à plusieurs niveaux n’est pas activée par défaut.

Une des tâches importantes effectuées par le compilateur JIT est l’optimisation de l’exécution du code. Toutefois, pour les chemins de code peu utilisés, le compilateur peut passer plus de temps à optimiser le code que le runtime passe à exécuter du code non optimisé. La compilation à plusieurs niveaux ajoute deux étapes à la compilation JIT :

  • Un premier niveau, qui génère du code aussi rapidement que possible.

  • Un second niveau, qui génère un code optimisé pour les méthodes fréquemment exécutées. Le second niveau de compilation est effectué en parallèle pour améliorer les performances.

Vous pouvez activer la compilation à plusieurs niveaux de deux manières.

  • Pour utiliser la compilation à plusieurs niveaux dans tous les projets qui utilisent le Kit de développement .NET Core 2.1, définissez la variable d’environnement suivante :

    COMPlus_TieredCompilation="1"

  • Pour utiliser la compilation à plusieurs niveaux par projet, ajoutez la propriété <TieredCompilation> à la section <PropertyGroup> du fichier projet MSBuild, comme le montre l’exemple suivant :

    <PropertyGroup>
    <!-- other property definitions -->

    <TieredCompilation>true</TieredCompilation>
</PropertyGroup>

Modifications d'API

Span<T> et Memory<T>

.NET Core 2.1 inclut certains nouveaux types qui facilitent l’utilisation de tableaux et d’autres types de mémoire beaucoup plus efficaces. Ces nouveaux types incluent :

Sans ces types, lorsque vous passez des éléments de ce type comme une partie d’un tableau ou d’une section d’une mémoire tampon, vous devez créer une copie d’une partie des données avant de les passer à une méthode. Ces types fournissent une représentation virtuelle des données, qui supprime les opérations supplémentaires d’allocation de mémoire et de copie.

L’exemple suivant utilise une instance Span<T> et Memory<T> pour fournir une représentation virtuelle de 10 éléments d’un tableau.

using System;

class Program
{
    static void Main()
    {
        int[] numbers = new int[100];
        for (int i = 0; i < 100; i++)
        {
            numbers[i] = i * 2;
        }

        var part = new Span<int>(numbers, start: 10, length: 10);
        foreach (var value in part)
            Console.Write($"{value}  ");
    }
}
// The example displays the following output:
//     20  22  24  26  28  30  32  34  36  38

Module Program
    Sub Main()
        Dim numbers As Integer() = New Integer(99) {}

        For i As Integer = 0 To 99
            numbers(i) = i * 2
        Next

        Dim part = New Memory(Of Integer)(numbers, start:=10, length:=10)

        For Each value In part.Span
            Console.Write($"{value}  ")
        Next
    End Sub
End Module
' The example displays the following output:
'     20  22  24  26  28  30  32  34  36  38

Compression de Brotli

.NET Core 2.1 prend en charge la compression et la décompression de Brotli. Brotli est un algorithme de compression sans perte à usage général, défini dans RFC 7932, et pris en charge par la plupart des navigateurs web et les principaux serveurs web. Vous pouvez utiliser une classe System.IO.Compression.BrotliStream basée sur les flux ou des classes hautes performances System.IO.Compression.BrotliEncoder et System.IO.Compression.BrotliDecoder basées sur la portée. L'exemple suivant montre une compression avec la classe BrotliStream :

public static Stream DecompressWithBrotli(Stream toDecompress)
{
    MemoryStream decompressedStream = new MemoryStream();
    using (BrotliStream decompressionStream = new BrotliStream(toDecompress, CompressionMode.Decompress))
    {
        decompressionStream.CopyTo(decompressedStream);
    }
    decompressedStream.Position = 0;
    return decompressedStream;
}

Public Function DecompressWithBrotli(toDecompress As Stream) As Stream
    Dim decompressedStream As New MemoryStream()
    Using decompressionStream As New BrotliStream(toDecompress, CompressionMode.Decompress)
        decompressionStream.CopyTo(decompressedStream)
    End Using
    decompressedStream.Position = 0
    Return decompressedStream
End Function

Le comportement de BrotliStream est identique à DeflateStream et GZipStream, ce qui facilite la convertir du code qui appelle ces API pour BrotliStream.

Nouvelles API de chiffrement et améliorations du chiffrement

.NET Core 2.1 inclut de nombreuses améliorations des API de chiffrement :

Améliorations des sockets

.NET Core inclut un nouveau type, System.Net.Http.SocketsHttpHandler, et une System.Net.Http.HttpMessageHandler réécrite, qui constituent la base des API de mise en réseau de niveau supérieur. System.Net.Http.SocketsHttpHandler, par exemple, est la base de l’implémentation HttpClient. Dans les versions précédentes de .NET Core, les API de niveau supérieur étaient basées sur des implémentations de mise en réseau natives.

L’implémentation de sockets introduite dans .NET Core 2.1 présente plusieurs avantages :

  • Une amélioration significative des performances par rapport à l’implémentation précédente.

  • La suppression des dépendances de plateforme, qui simplifie le déploiement et la maintenance.

  • Comportement cohérent sur toutes les plates-formes .NET Core.

SocketsHttpHandler est l’implémentation par défaut dans .NET Core 2.1. Toutefois, vous pouvez configurer votre application pour utiliser l’ancienne classe HttpClientHandler en appelant la méthode AppContext.SetSwitch :

AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", false);

AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", False)

Vous pouvez également utiliser une variable d’environnement pour désactiver l’utilisation des implémentations de sockets basées sur SocketsHttpHandler. Pour cela, définissez DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER sur false ou 0.

Sous Windows, vous pouvez également choisir d’utiliser System.Net.Http.WinHttpHandler, repose sur une implémentation native, ou la classe SocketsHttpHandler en passant une instance de la classe au constructeur HttpClient.

Sous Linux et macOS, vous pouvez uniquement configurer HttpClient par processus. Sous Linux, vous devez déployer libcurl si vous souhaitez utiliser l’ancienne implémentation HttpClient. (Il est installé avec .NET Core 2.0.)

Changements cassants

Pour plus d’informations sur les changements cassants, consultez Changements cassants pour la migration de la version 2.0 vers la version 2.1.

Voir aussi