Delen via

Nieuw in .NET Core 2.1

  • Artikel

.NET Core 2.1 bevat verbeteringen en nieuwe functies op de volgende gebieden:

Hulpprogramma's

De .NET Core 2.1 SDK (v 2.1.300), de hulpprogramma's die deel uitmaken van .NET Core 2.1, bevatten de volgende wijzigingen en verbeteringen:

Prestatieverbeteringen bouwen

Een belangrijke focus van .NET Core 2.1 is het verbeteren van de prestaties van de buildtijd, met name voor incrementele builds. Deze prestatieverbeteringen zijn van toepassing op zowel opdrachtregel-builds als dotnet build op builds in Visual Studio. Enkele afzonderlijke verbeteringsgebieden zijn:

  • Voor pakketassetomzetting worden alleen assets omgezet die worden gebruikt door een build in plaats van alle assets.

  • Cache van assemblyverwijzingen.

  • Gebruik van langlopende SDK-buildservers. Dit zijn processen die betrekking hebben op afzonderlijke dotnet build aanroepen. Ze elimineren de noodzaak om grote codeblokken met JIT te compileren telkens wanneer dotnet build deze wordt uitgevoerd. Build-serverprocessen kunnen automatisch worden beëindigd met de volgende opdracht:

    dotnet buildserver shutdown

Nieuwe CLI-opdrachten

Een aantal hulpprogramma's die alleen per project DotnetCliToolReference beschikbaar waren, zijn nu beschikbaar als onderdeel van de .NET Core SDK. Tot deze hulpmiddelen behoren onder meer:

  • dotnet watch biedt een bestandssysteem-watcher die wacht totdat een bestand wordt gewijzigd voordat een aangewezen set opdrachten wordt uitgevoerd. Met de volgende opdracht wordt bijvoorbeeld het huidige project automatisch opnieuw opgebouwd en wordt uitgebreide uitvoer gegenereerd wanneer een bestand in het project wordt gewijzigd:

    dotnet watch -- --verbose build

    Let op de -- optie die voorafgaat aan de --verbose optie. Hiermee worden de opties die rechtstreeks aan de dotnet watch opdracht worden doorgegeven, gescheiden van de argumenten die worden doorgegeven aan het onderliggende dotnet proces. Zonder deze optie is de --verbose optie van toepassing op de dotnet watch opdracht, niet op de dotnet build opdracht.

    Zie Ontwikkelen ASP.NET Core-apps met dotnet Watch voor meer informatie.

  • dotnet dev-certs genereert en beheert certificaten die tijdens de ontwikkeling worden gebruikt in ASP.NET Core-toepassingen.

  • dotnet user-secrets beheert de geheimen in een gebruikersgeheimarchief in ASP.NET Core-toepassingen.

  • dotnet sql-cache maakt een tabel en indexen in een Microsoft SQL Server-database die moet worden gebruikt voor gedistribueerde caching.

  • dotnet ef is een hulpprogramma voor het beheren van databases, DbContext objecten en migraties in Entity Framework Core-toepassingen. Zie EF Core .NET-opdrachtregelprogramma's voor meer informatie.

Algemene hulpprogramma's

.NET Core 2.1 biedt ondersteuning voor Global Tools, dat wil gezegd, aangepaste hulpprogramma's die wereldwijd beschikbaar zijn vanaf de opdrachtregel. Het uitbreidbaarheidsmodel in eerdere versies van .NET Core maakte aangepaste hulpprogramma's per project alleen beschikbaar met behulp van DotnetCliToolReference.

Als u een algemeen hulpprogramma wilt installeren, gebruikt u de opdracht voor het installeren van het dotnet-hulpprogramma. Voorbeeld:

dotnet tool install -g dotnetsay

Nadat het hulpprogramma is geïnstalleerd, kan het vanaf de opdrachtregel worden uitgevoerd door de naam van het hulpprogramma op te geven. Zie het overzicht van .NET Core Global Tools voor meer informatie.

Hulpprogrammabeheer met de dotnet tool opdracht

In .NET Core 2.1 SDK gebruiken alle hulpprogramma's de dotnet tool opdracht. De volgende opties zijn beschikbaar:

Vooruitdraaien

Alle .NET Core-toepassingen die beginnen met .NET Core 2.0 worden automatisch doorgestuurd naar de nieuwste secundaire versie die op een systeem is geïnstalleerd.

Vanaf .NET Core 2.0, als de versie van .NET Core waarmee een toepassing is gebouwd, niet aanwezig is tijdens de runtime, wordt de toepassing automatisch uitgevoerd op de meest recente geïnstalleerde secundaire versie van .NET Core. Met andere woorden, als een toepassing is gebouwd met .NET Core 2.0 en .NET Core 2.0 niet aanwezig is op het hostsysteem, maar .NET Core 2.1 is, wordt de toepassing uitgevoerd met .NET Core 2.1.

Belangrijk

Dit roll-forward-gedrag is niet van toepassing op preview-releases. De standaardinstelling is ook niet van toepassing op belangrijke releases, maar dit kan worden gewijzigd met de onderstaande instellingen.

U kunt dit gedrag wijzigen door de instelling voor de roll-forward te wijzigen voor geen gedeeld kandidaatframework. De volgende instellingen zijn beschikbaar:

  • 0 - schakel het gedrag voor het doorsturen van secundaire versies uit. Met deze instelling wordt een toepassing die is gebouwd voor .NET Core 2.0.0, doorgestuurd naar .NET Core 2.0.1, maar niet naar .NET Core 2.2.0 of .NET Core 3.0.0.
  • 1 - schakel het gedrag voor het doorsturen van secundaire versies in. Dit is de standaardwaarde voor de instelling. Met deze instelling wordt een toepassing die is gebouwd voor .NET Core 2.0.0, doorgestuurd naar .NET Core 2.0.1 of .NET Core 2.2.0, afhankelijk van welke is geïnstalleerd, maar wordt deze niet doorgestuurd naar .NET Core 3.0.0.
  • 2 - schakel het gedrag voor de roll-forward van secundaire en primaire versie in. Als deze optie is ingesteld, worden zelfs verschillende primaire versies overwogen, zodat een toepassing die is gebouwd voor .NET Core 2.0.0, wordt doorgestuurd naar .NET Core 3.0.0.

U kunt deze instelling op drie manieren wijzigen:

  • Stel de DOTNET_ROLL_FORWARD_ON_NO_CANDIDATE_FX omgevingsvariabele in op de gewenste waarde.

  • Voeg de volgende regel met de gewenste waarde toe aan het bestand .runtimeconfig.json :

    "rollForwardOnNoCandidateFx" : 0

  • Wanneer u de .NET CLI gebruikt, voegt u de volgende optie met de gewenste waarde toe aan een .NET-opdracht, zoals run:

    dotnet run --rollForwardOnNoCandidateFx=0

Roll forward van patchversies is onafhankelijk van deze instelling en wordt uitgevoerd nadat een mogelijke secundaire of primaire versie-roll forward is toegepast.

Implementatie

Zelf-ingesloten toepassingsonderhoud

dotnet publish publiceert nu zelfstandige toepassingen met een serviceruntimeversie. Wanneer u een zelfstandige toepassing publiceert met de .NET Core 2.1 SDK (v 2.1.300), bevat uw toepassing de nieuwste serviceruntimeversie die bekend is door die SDK. Wanneer u een upgrade uitvoert naar de nieuwste SDK, publiceert u met de nieuwste .NET Core-runtimeversie. Dit geldt voor .NET Core 1.0-runtimes en hoger.

Zelfstandige publicatie is afhankelijk van runtimeversies op NuGet.org. U hoeft de serviceruntime niet op uw computer te hebben.

Met behulp van de .NET Core 2.0 SDK worden zelfstandige toepassingen gepubliceerd met de .NET Core 2.0.0-runtime, tenzij een andere versie wordt opgegeven via de RuntimeFrameworkVersion eigenschap. Met dit nieuwe gedrag hoeft u deze eigenschap niet meer in te stellen om een hogere runtimeversie te selecteren voor een zelfstandige toepassing. De eenvoudigste benadering is altijd publiceren met .NET Core 2.1 SDK (v 2.1.300).

Zie Voor meer informatie, self-contained deployment runtime roll forward.

Windows-compatibiliteitspakket

Wanneer u bestaande code van .NET Framework overzet naar .NET Core, kunt u het Windows-compatibiliteitspakket gebruiken. Het biedt toegang tot 20.000 meer API's dan beschikbaar zijn in .NET Core. Deze API's omvatten typen in de System.Drawing naamruimte, de EventLog klasse, WMI, Prestatiemeteritems, Windows Services en de Windows-registertypen en -leden.

JIT-compilerverbeteringen

.NET Core bevat een nieuwe JIT-compilertechnologie genaamd gelaagde compilatie (ook wel adaptieve optimalisatie genoemd) die de prestaties aanzienlijk kan verbeteren. Gelaagde compilatie is een opt-in-instelling.

Een van de belangrijke taken die door de JIT-compiler worden uitgevoerd, is het optimaliseren van de uitvoering van code. Voor weinig gebruikte codepaden kan de compiler echter meer tijd besteden aan het optimaliseren van code dan de runtime besteedt aan het uitvoeren van niet-geoptimaliseerde code. Gelaagde compilatie introduceert twee fasen in JIT-compilatie:

  • Een eerste laag, waarmee code zo snel mogelijk wordt gegenereerd.

  • Een tweede laag, waarmee geoptimaliseerde code wordt gegenereerd voor methoden die regelmatig worden uitgevoerd. De tweede compilatielaag wordt parallel uitgevoerd voor verbeterde prestaties.

U kunt kiezen voor gelaagde compilatie op twee manieren.

  • Als u gelaagde compilatie wilt gebruiken in alle projecten die gebruikmaken van de .NET Core 2.1 SDK, stelt u de volgende omgevingsvariabele in:

    COMPlus_TieredCompilation="1"

  • Als u gelaagde compilatie per project wilt gebruiken, voegt u de <TieredCompilation> eigenschap toe aan de <PropertyGroup> sectie van het MSBuild-projectbestand, zoals in het volgende voorbeeld wordt weergegeven:

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

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

API-wijzigingen

Span<T> en Memory<T>

.NET Core 2.1 bevat enkele nieuwe typen die het werken met matrices en andere soorten geheugen veel efficiënter maken. De nieuwe typen zijn onder andere:

Zonder deze typen moet u bij het doorgeven van items als een gedeelte van een matrix of een sectie van een geheugenbuffer een kopie maken van een deel van de gegevens voordat u deze doorgeeft aan een methode. Deze typen bieden een virtuele weergave van die gegevens waardoor de extra geheugentoewijzing en kopieerbewerkingen niet meer nodig zijn.

In het volgende voorbeeld wordt een Span<T> en Memory<T> exemplaar gebruikt om een virtuele weergave van 10 elementen van een matrix te bieden.

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-compressie

.NET Core 2.1 voegt ondersteuning toe voor Brotli-compressie en -decompressie. Brotli is een algemeen verliesloos compressie-algoritme dat is gedefinieerd in RFC 7932 en wordt ondersteund door de meeste webbrowsers en belangrijke webservers. U kunt de streamklasse System.IO.Compression.BrotliStream of de high-performance span-based System.IO.Compression.BrotliEncoder and System.IO.Compression.BrotliDecoder classes gebruiken. In het volgende voorbeeld ziet u compressie met de BrotliStream klasse:

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

Het BrotliStream gedrag is hetzelfde als DeflateStream en GZipStream, waardoor het eenvoudig is om code te converteren die deze API's aanroept.BrotliStream

Nieuwe cryptografie-API's en verbeteringen in cryptografie

.NET Core 2.1 bevat tal van verbeteringen in de cryptografie-API's:

Verbeteringen aan sockets

.NET Core bevat een nieuw type, System.Net.Http.SocketsHttpHandleren een herschreven System.Net.Http.HttpMessageHandler, die de basis vormen van netwerk-API's op een hoger niveau. System.Net.Http.SocketsHttpHandleris bijvoorbeeld de basis van de HttpClient implementatie. In eerdere versies van .NET Core waren API's op een hoger niveau gebaseerd op systeemeigen netwerkimplementaties.

De sockets-implementatie die is geïntroduceerd in .NET Core 2.1 heeft een aantal voordelen:

  • Een aanzienlijke prestatieverbetering in vergelijking met de vorige implementatie.

  • Verwijdering van platformafhankelijkheden, wat de implementatie en het onderhoud vereenvoudigt.

  • Consistent gedrag voor alle .NET Core-platforms.

SocketsHttpHandler is de standaard implementatie in .NET Core 2.1. U kunt uw toepassing echter configureren om de oudere HttpClientHandler klasse te gebruiken door de AppContext.SetSwitch methode aan te roepen:

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

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

U kunt ook een omgevingsvariabele gebruiken om af te zien van het gebruik van sockets-implementaties op SocketsHttpHandlerbasis van . Hiervoor stelt u de optie in DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER op of false 0.

In Windows kunt u er ook voor kiezen om te gebruiken System.Net.Http.WinHttpHandler, die afhankelijk is van een systeemeigen implementatie of de SocketsHttpHandler klasse door een exemplaar van de klasse door te geven aan de HttpClient constructor.

In Linux en macOS kunt u alleen per proces configureren HttpClient . In Linux moet u libcurl implementeren als u de oude HttpClient implementatie wilt gebruiken. (Het is geïnstalleerd met .NET Core 2.0.)

Wijzigingen die fouten veroorzaken

Zie Belangrijke wijzigingen voor migratie van versie 2.0 naar 2.1 voor informatie over belangrijke wijzigingen.

Zie ook