Neuigkeiten in .NET Core 2.1

  • Artikel

.NET Core 2.1 enthält Verbesserungen und neue Features in folgenden Bereichen:

Tools

Das .NET Core 2.1 SDK (Version 2.1.300), die in .NET Core 2.1 enthaltenen Tools, enthält die folgenden Änderungen und Verbesserungen:

Buildleistungsverbesserungen

Ein wichtiger Schwerpunkt von .NET Core 2.1 ist die Verbesserung der Buildzeitleistung, insbesondere bei inkrementellen Builds. Diese Leistungsverbesserungen gelten sowohl für beide Befehlszeilenbuilds mit dotnet build als auch Builds in Visual Studio. Einige individuelle Verbesserungsbereiche sind:

  • Bei der Auflösung von Paketressourcen werden statt aller Ressourcen nur die von einem Build verwendeten Ressourcen aufgelöst.

  • Zwischenspeichern von Assemblyverweisen.

  • Verwendung von SDK-Buildservern mit langer Ausführungszeit, wobei es sich um Prozesse handelt, die sich über einzelne dotnet build-Aufrufe erstrecken. Sie machen die Notwendigkeit der JIT-Kompilierung großer Codeblöcke bei jeder Ausführung von dotnet build überflüssig. Buildserverprozesse können automatisch mithilfe des folgenden Befehls beendet werden:

    dotnet buildserver shutdown

Neue CLI-Befehle

Eine Reihe von Tools, die nur auf Projektbasis unter Verwendung von DotnetCliToolReference verfügbar waren, steht jetzt als Teil des .NET Core SDK zur Verfügung. Zu diesen Tools gehören:

  • dotnet watch bietet eine Dateisystemüberwachung, die vor der Ausführung eines designierten Satzes von Befehlen auf die Änderung einer Datei wartet. Der folgende Befehl erstellt beispielsweise automatisch das aktuelle Projekt neu und generiert eine ausführliche Ausgabe, sobald sich eine Datei darin ändert:

    dotnet watch -- --verbose build

    Beachten Sie, dass die ---Option der --verbose-Option vorausgeht. Sie begrenzt die Optionen, die dem dotnet watch-Befehl direkt von den Argumenten übergeben werden, die dem untergeordneten dotnet-Prozess übergeben werden. Ohne sie gilt die --verbose-Option für den dotnet watch-Befehl, nicht den dotnet build-Befehl.

    Weitere Informationen finden Sie unter Entwickeln von ASP.NET Core-Apps mit dotnet watch.

  • dotnet dev-certs generiert und verwaltet Zertifikate, die während der Entwicklung in ASP.NET Core-Anwendungen verwendet werden.

  • dotnet user-secrets verwaltet die Geheimnisse in einem Benutzergeheimnisspeicher in ASP.NET Core-Anwendungen.

  • dotnet sql-cache erstellt eine Tabelle und Indizes für Distributed Caching in einer Microsoft SQL Server-Datenbank.

  • dotnet ef ist ein Tool zum Verwalten von Datenbanken, DbContext-Objekten und Migrationen in Entity Framework Core-Anwendungen. Weitere Informationen finden Sie unter EF Core .NET-Befehlszeilentools.

Globale Tools

.NET Core 2.1 unterstützt globale Tools – d.h. benutzerdefinierte Tools, die global über die Befehlszeile verfügbar sind. Das Erweiterbarkeitsmodell in früheren Versionen von benutzerdefinierten .NET Core-Tools ist auf Projektbasis nur mithilfe von DotnetCliToolReference verfügbar.

Verwenden Sie den dotnet tool install-Befehl, um ein globales Tool zu installieren. Zum Beispiel:

dotnet tool install -g dotnetsay

Nach Abschluss der Installation kann das Tool durch Angeben seines Namens in der Befehlszeile ausgeführt werden. Weitere Informationen finden Sie unter Übersicht über globale .NET Core-Tools.

Toolverwaltung mit dem dotnet tool-Befehl

In .NET Core SDK 2.1 verwenden alle Toolsvorgänge den dotnet tool-Befehl. Die folgenden Optionen sind verfügbar:

Rollforward

Ab .NET Core 2.0 wird für alle .NET Core-Anwendungen automatisch ein Rollforward auf die neueste Nebenversion auf einem System installiert.

Wenn die Version von .NET Core, mit der eine Anwendung erstellt wurde, nicht zur Runtime vorhanden ist, wird die Anwendung ab .NET Core 2.0 automatisch für die neueste installierte Nebenversion von .NET Core ausgeführt. Das heißt, wenn eine Anwendung mit .NET Core 2.0 erstellt wurde, und .NET Core 2.0 auf dem Hostsystem nicht vorhanden ist, jedoch .NET Core 2.1, wird die Anwendung mit .NET Core 2.1 ausgeführt.

Wichtig

Dieses Rollforwardverhalten gilt nicht für Vorschauversionen. Es wird standardmäßig auch nicht auf Hauptreleases angewendet. Dies können Sie mit den folgenden Einstellungen jedoch ändern.

Sie können dieses Verhalten anpassen, indem Sie die Einstellung für den Rollforward auf das freigegebene Framework ohne Candidate. Folgende Einstellungen sind verfügbar:

  • 0: Das Rollforwardverhalten für Nebenversionen deaktivieren. Mit dieser Einstellung wird für Anwendungen für .NET Core 2.0.0 ein Rollforward auf .NET Core 2.0.1 ausgeführt, aber nicht für .NET Core 2.2.0 oder .NET Core 3.0.0.
  • 1: Das Rollforwardverhalten für Nebenversionen aktivieren. Dies ist die Standardeinstellung. Mit dieser Einstellung wird für Anwendungen für .NET Core 2.0.0 ein Rollforward auf .NET Core 2.0.1 oder .NET Core 2.2.0 abhängig davon ausgeführt, was installiert wird. Es wird jedoch kein Rollforward auf .NET Core 3.0.0 ausgeführt.
  • 2: Das Rollforwardverhalten für Neben- und Hauptversionen aktivieren. Wenn diese Einstellung festgelegt wird, werden auch verschiedene Hauptversionen für das Rollforwardverhalten beachtet, d. h., für Anwendungen für .NET Core 2.0.0 wird ein Rollforward auf .NET Core 3.0.0 ausgeführt.

Sie können diese Einstellung auf drei verschiedene Arten ändern:

  • Legen Sie den gewünschten Wert für die Umgebungsvariable DOTNET_ROLL_FORWARD_ON_NO_CANDIDATE_FX fest.

  • Fügen Sie die folgende Zeile mit dem gewünschten Wert in die Datei .runtimeconfig.json ein:

    "rollForwardOnNoCandidateFx" : 0

  • Fügen Sie bei Verwendung der .NET Core-CLI die folgende Option mit dem gewünschten Wert zu einem .NET Core-Befehl wie run hinzu:

    dotnet run --rollForwardOnNoCandidateFx=0

Rollforwards für die Patchversionen sind unabhängig von dieser Einstellung und erfolgen erst, nachdem Rollforwards für Neben- und Hauptversionen ausgeführt wurden.

Bereitstellung

Wartung einer eigenständigen Anwendung

dotnet publish veröffentlicht jetzt eigenständige Anwendungen mit einer gewarteten Runtimeversion. Wenn Sie eine eigenständige Anwendung mit dem .NET Core 2.1 SDK (Version 2.1.300) veröffentlichen, enthält Ihre Anwendung die neueste gewartete Runtimeversion, die diesem SDK bekannt ist. Wenn Sie auf das neueste SDK aktualisieren, veröffentlichen Sie mit der neuesten .NET Core-Runtimeversion. Dies gilt für Runtimes ab .NET Core 1.0.

Eigenständige Veröffentlichung basiert auf Runtimeversionen auf „NuGet.org“. Die gewartete Runtime muss nicht auf Ihrem Computer vorhanden sein.

Bei Verwendung von .NET Core 2.0 SDK werden eigenständige Anwendungen mit der .NET Core 2.0.0-Runtime veröffentlicht, solange keine andere Version über die RuntimeFrameworkVersion-Eigenschaft angegeben wird. Mit diesem neuen Verhalten müssen Sie diese Eigenschaft nicht mehr festlegen, um eine höhere Runtimeversion für eine eigenständige Anwendung auszuwählen. Der einfachste Ansatz, auf eine höhere Version zu aktualisieren, besteht darin, immer mit .NET Core 2.1 SDK (Version 2.1.300) zu veröffentlichen.

Weitere Informationen finden Sie unter Rollforward der eigenständigen Runtimebereitstellung.

Windows Compatibility Pack

Wenn Sie vorhandenen Code aus .NET Framework zu .NET Core portieren, können Sie das Windows Compatibility Pack verwenden. Es bietet Zugriff auf 20.000 APIs mehr, als in .NET Core verfügbar sind. Zu diesen APIs zählen Typen in System.Drawing-Namespace, EventLog-Klasse, WMI, Leistungsindikatoren, Windows-Diensten sowie die Windows-Registrierungstypen und Member.

Verbesserungen am JIT-Compiler

.NET Core umfasst eine neue JIT-Compiler-Technologie namens mehrstufige Kompilierung (auch bekannt als adaptive Optimierung), die die Leistung erheblich verbessern kann. Mehrstufige Kompilierung ist eine optionale Einstellung.

Eine der wichtigen Aufgaben, die vom JIT-Compiler ausgeführt werden, ist die Optimierung der Ausführung des Codes. Für wenig genutzte Codepfade muss der Compiler jedoch möglicherweise mehr Zeit zur Optimierung des Codes aufbringen, als die Runtime zur Ausführung nicht optimierten Codes benötigt. Die mehrstufige Kompilierung unterteilt die JIT-Kompilierung in zwei Phasen:

  • Eine erste Stufe, die so schnell wie möglich Code generiert.

  • Eine zweite Stufe, die optimiertem Code für Methoden generiert, die häufig ausgeführt werden. Die zweite Stufe der Kompilierung wird parallel zum Verbessern der Leistung ausgeführt.

Zum Aktivieren der mehrstufigen Kompilierung können Sie zwischen zwei Arten wählen.

  • Um mehrstufige Kompilierung in allen Projekten einzusetzen, die das .NET Core 2.1 SDK verwenden, legen Sie die folgende Umgebungsvariable fest:

    COMPlus_TieredCompilation="1"

  • Um mehrstufige Kompilierung in ausgewählten Projekten einzusetzen, fügen Sie die <TieredCompilation>-Eigenschaft dem <PropertyGroup>-Abschnitt der MSBuild-Projektdatei hinzu, wie im folgenden Beispiel gezeigt:

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

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

API-Änderungen

Span<T> und Memory<T>

.NET Core 2.1 enthält einige neue Typen, die das Arbeiten mit Arrays und anderen Arten von Arbeitsspeicher wesentlich effizienter machen. Die neuen Typen umfassen:

Ohne diese Typen müssen Sie bei der Übergabe solcher Elemente als Teil eines Arrays oder Abschnitt eines Arbeitsspeicherpuffers eine Kopie eines Teils der Daten anfertigen, bevor Sie sie einer Methode übergeben. Diese Typen bieten eine virtuelle Sicht der Daten, die die zusätzliche Speicherzuweisung und Kopiervorgänge überflüssig macht.

Das folgende Beispiel verwendet eine Span<T>- und eine Memory<T>-Instanz, um eine virtuelle Ansicht von 10 Elementen eines Arrays bereitzustellen.

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

Brotli-Komprimierung

Ab .NET Core 2.1 werden Brotli-Komprimierung und -Dekomprimierung unterstützt. Brotli ist ein allgemein einsetzbarer verlustfreier Komprimierungsalgorithmus, der in RFC 7932 definiert ist und von den meisten Webbrowsern und den wichtigsten Webservern unterstützt wird. Sie können die streambasierte System.IO.Compression.BrotliStream-Klasse oder die leistungsstarken, bereichsbasierten Klassen System.IO.Compression.BrotliEncoder und System.IO.Compression.BrotliDecoder verwenden. Im folgenden Beispiel wird die Komprimierung mit der BrotliStream-Klasse veranschaulicht:

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

Das BrotliStream-Verhalten entspricht dem von DeflateStream und GZipStream. Dies vereinfacht das Konvertieren von Code, der diese APIs nach BrotliStream aufruft.

Neue Kryptografie-APIs und Kryptografieverbesserungen

.NET Core 2.1 enthält zahlreiche Verbesserungen der Kryptografie-APIs:

Socketverbesserungen

.NET Core umfasst einen neuen Typ, System.Net.Http.SocketsHttpHandler, und einen umgeschriebenen, System.Net.Http.HttpMessageHandler, die gemeinsam die Basis der Netzwerk-APIs auf höherer Ebene bilden. System.Net.Http.SocketsHttpHandler ist z.B. die Grundlage der HttpClient-Implementierung. In früheren Versionen von .NET Core basierten APIs auf höherer Ebene auf nativen Netzwerkimplementierungen.

Die in .NET Core 2.1 eingeführte Socketimplementierung hat eine Reihe von Vorteilen:

  • Eine beträchtliche Leistungssteigerung im Vergleich zur früheren Implementierung.

  • Plattformabhängigkeiten wurden eliminiert, was Bereitstellung und Wartung vereinfacht.

  • Einheitliches Verhalten auf allen .NET Core-Plattformen.

SocketsHttpHandler ist die Standardimplementierung in .NET Core 2.1. Allerdings können Sie Ihre Anwendung mit der älteren HttpClientHandler-Klasse durch Aufrufen der AppContext.SetSwitch-Methode konfigurieren:

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

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

Statt auf SocketsHttpHandler basierender Socketimplementierungen können Sie auch eine Umgebungsvariable verwenden. Legen Sie dazu für DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER entweder false oder 0 (null) fest.

Unter Windows können Sie auch System.Net.Http.WinHttpHandler verwenden, was von einer nativen Implementierung abhängt, oder die SocketsHttpHandler-Klasse durch Übergabe einer Instanz der Klasse an den HttpClient-Konstruktor.

Auf Linux und macOS können Sie HttpClient nur pro Prozess konfigurieren. Unter Linux müssen Sie libcurl bereitstellen, wenn Sie die alte HttpClient-Implementierung verwenden möchten. (Wird mit .NET Core 2.0 installiert.)

Breaking Changes

Informationen zu Breaking Changes finden Sie unter Breaking Changes für die Migration von Version 2.0 zu 2.1.

Siehe auch