Neuigkeiten in .NET Core 2.1
.NET Core 2.1 enthält Verbesserungen und neue Features in folgenden Bereichen:
- Tools
- Rollforward
- Bereitstellung
- Windows Compatibility Pack
- JIT-Kompilierungsverbesserungen
- API-Änderungen
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 vondotnet 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 demdotnet watch
-Befehl direkt von den Argumenten übergeben werden, die dem untergeordnetendotnet
-Prozess übergeben werden. Ohne sie gilt die--verbose
-Option für dendotnet watch
-Befehl, nicht dendotnet 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:
dotnet tool install
zum Installieren eines Tools.dotnet tool update
zum Deinstallieren und Neuinstallieren eines Tools, wodurch es eigentlich aktualisiert wird.dotnet tool list
zum Auflisten derzeit installierter Tools.dotnet tool uninstall
zum Deinstallieren derzeit installierter Tools.
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:
System.Security.Cryptography.Pkcs.SignedCms ist im Paket System.Security.Cryptography.Pkcs verfügbar. Die Implementierung ist identisch mit jener der SignedCms-Klasse in .NET Framework.
Neue Überladungen der X509Certificate.GetCertHash- und X509Certificate.GetCertHashString-Methode akzeptieren einen Hashalgorithmusbezeichner, um Aufrufern zu ermöglichen, Zertifikatfingerabdruck-Werte mit anderen Algorithmen als SHA-1 zu erhalten.
Neue Kryptografie-APIs auf Span<T>-Basis stehen für Hashvorgänge, HMAC, kryptografische Zufallszahlengenerierung, asymmetrische Signaturgenerierung, asymmetrische Signaturverarbeitung und RSA-Verschlüsselung zur Verfügung.
Die Leistung von System.Security.Cryptography.Rfc2898DeriveBytes wurde mithilfe einer Span<T>-basierten Implementierung um ca. 15% verbessert.
Die neue System.Security.Cryptography.CryptographicOperations-Klasse enthält zwei neue Methoden:
FixedTimeEquals benötigt eine feste Zeitspanne zur Rückgabe von zwei beliebigen Eingaben derselben Länge, sodass sie zur Verwendung bei kryptografischer Überprüfung geeignet ist, um zu vermeiden, das zu Zeitsteuerungs-Seitenkanalinformationen beigetragen wird.
ZeroMemory ist eine Arbeitsspeicherlöschroutine, die nicht optimiert werden kann.
Die statische RandomNumberGenerator.Fill-Methode füllt eine Span<T> mit Zufallswerten.
Die System.Security.Cryptography.Pkcs.EnvelopedCms-Methode wird jetzt unter Linux und macOS unterstützt.
Elliptic-Curve Diffie-Hellman (ECDH) steht jetzt in der System.Security.Cryptography.ECDiffieHellman-Klassenfamilie zur Verfügung. Der Oberflächenbereich ist mit dem von .NET Framework identisch.
Die von RSA.Create zurückgegebene Instanz kann mit OAEP mit einem SHA-2-Hashwert verschlüsseln oder entschlüsseln als auch Signaturen mit RSA-PSS generieren oder überprüfen.
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
Feedback
Feedback senden und anzeigen für