Dela via

Nyheter i .NET Core 2.1

  • Artikel

.NET Core 2.1 innehåller förbättringar och nya funktioner inom följande områden:

Verktyg

.NET Core 2.1 SDK (v 2.1.300), verktygen som ingår i .NET Core 2.1, innehåller följande ändringar och förbättringar:

Förbättringar av byggprestanda

Ett stort fokus för .NET Core 2.1 är att förbättra byggtidsprestanda, särskilt för inkrementella versioner. Dessa prestandaförbättringar gäller både kommandoradsversioner med hjälp av dotnet build och för versioner i Visual Studio. Några av de enskilda förbättringsområdena är:

  • För lösning av pakettillgångar löser du endast tillgångar som används av en version i stället för alla tillgångar.

  • Cachelagring av sammansättningsreferenser.

  • Användning av långvariga SDK-byggservrar, som är processer som sträcker sig över enskilda dotnet build anrop. De eliminerar behovet av att JIT-kompilera stora kodblock varje gång dotnet build som körs. Byggserverprocesser kan avslutas automatiskt med följande kommando:

    dotnet buildserver shutdown

Nya CLI-kommandon

Ett antal verktyg som endast var tillgängliga per projekt DotnetCliToolReference är nu tillgängliga som en del av .NET Core SDK. Dessa verktyg innefattar:

  • dotnet watch tillhandahåller en filsystemsvakt som väntar på att en fil ska ändras innan en angiven uppsättning kommandon körs. Följande kommando återskapar till exempel automatiskt det aktuella projektet och genererar utförliga utdata när en fil i det ändras:

    dotnet watch -- --verbose build

    Observera det -- alternativ som föregår alternativet --verbose . Den avgränsar de alternativ som skickas direkt till dotnet watch kommandot från argumenten som skickas till den underordnade dotnet processen. Utan det gäller alternativet --verbose för dotnet watch kommandot, inte dotnet build kommandot.

    Mer information finns i Utveckla ASP.NET Core-appar med dotnet watch.

  • dotnet dev-certs genererar och hanterar certifikat som används under utveckling i ASP.NET Core-program.

  • dotnet user-secrets hanterar hemligheterna i ett användarhemlighetsarkiv i ASP.NET Core-program.

  • dotnet sql-cache skapar en tabell och index i en Microsoft SQL Server-databas som ska användas för distribuerad cachelagring.

  • dotnet ef är ett verktyg för att hantera databaser, DbContext objekt och migreringar i Entity Framework Core-program. Mer information finns i EF Core .NET-kommandoradsverktyg.

Globala verktyg

.NET Core 2.1 har stöd för globala verktyg , dvs. anpassade verktyg som är tillgängliga globalt från kommandoraden. Utökningsmodellen i tidigare versioner av .NET Core gjorde endast anpassade verktyg tillgängliga per projekt med hjälp DotnetCliToolReferenceav .

Om du vill installera ett globalt verktyg använder du installationskommandot för dotnet-verktyget. Till exempel:

dotnet tool install -g dotnetsay

När verktyget har installerats kan det köras från kommandoraden genom att ange verktygsnamnet. Mer information finns i översikten över .NET Core Global Tools.

Verktygshantering dotnet tool med kommandot

I .NET Core 2.1 SDK använder dotnet tool alla verktygsåtgärder kommandot . Följande alternativ är tillgängliga:

Rulla framåt

Alla .NET Core-program som börjar med .NET Core 2.0 överförs automatiskt till den senaste delversionen som är installerad på ett system.

Från och med .NET Core 2.0, om den version av .NET Core som ett program skapades med inte finns vid körning, körs programmet automatiskt mot den senaste installerade delversionen av .NET Core. Om ett program med andra ord har skapats med .NET Core 2.0 och .NET Core 2.0 inte finns i värdsystemet, men .NET Core 2.1 är det, körs programmet med .NET Core 2.1.

Viktigt!

Det här roll-forward-beteendet gäller inte för förhandsversioner. Som standard gäller det inte heller för större versioner, men detta kan ändras med inställningarna nedan.

Du kan ändra det här beteendet genom att ändra inställningen för framåtrullningen i inget delat ramverk för kandidater. Följande inställningar finns:

  • 0 – inaktivera roll-forward-beteende för delversion. Med den här inställningen rullar ett program som skapats för .NET Core 2.0.0 vidare till .NET Core 2.0.1, men inte till .NET Core 2.2.0 eller .NET Core 3.0.0.
  • 1 – aktivera roll-forward-beteende för delversion. Det här är standardvärdet för inställningen. Med den här inställningen kommer ett program som skapats för .NET Core 2.0.0 att rullas vidare till antingen .NET Core 2.0.1 eller .NET Core 2.2.0, beroende på vilken som är installerad, men det kommer inte att distribueras till .NET Core 3.0.0.
  • 2 – aktivera roll-forward-beteende för delversion och huvudversion. Om det anges kommer även olika huvudversioner att övervägas, så ett program som skapats för .NET Core 2.0.0 kommer att distribueras till .NET Core 3.0.0.

Du kan ändra den här inställningen på något av tre sätt:

  • DOTNET_ROLL_FORWARD_ON_NO_CANDIDATE_FX Ange miljövariabeln till önskat värde.

  • Lägg till följande rad med önskat värde i filen .runtimeconfig.json :

    "rollForwardOnNoCandidateFx" : 0

  • När du använder .NET CLI lägger du till följande alternativ med önskat värde i ett .NET-kommando, till exempel run:

    dotnet run --rollForwardOnNoCandidateFx=0

Återställning av korrigeringsversioner är oberoende av den här inställningen och görs efter att eventuell delversion eller större versionsfördrullning har tillämpats.

Distribution

Självbetjäning av program

dotnet publish publicerar nu fristående program med en tjänstbaserad körningsversion. När du publicerar ett fristående program med .NET Core 2.1 SDK (v 2.1.300) innehåller programmet den senaste serviceversion som SDK:et känner till. När du uppgraderar till den senaste SDK:en publicerar du med den senaste .NET Core-körningsversionen. Detta gäller för .NET Core 1.0-körningar och senare.

Fristående publicering bygger på körningsversioner på NuGet.org. Du behöver inte ha den tjänstindelade körningen på datorn.

Med hjälp av .NET Core 2.0 SDK publiceras fristående program med .NET Core 2.0.0-körningen om inte en annan version anges via RuntimeFrameworkVersion egenskapen. Med det här nya beteendet behöver du inte längre ange den här egenskapen för att välja en högre körningsversion för ett fristående program. Den enklaste metoden framöver är att alltid publicera med .NET Core 2.1 SDK (v 2.1.300).

Mer information finns i Distributionskörning för fristående distribution framåt.

Windows-kompatibilitetspaket

När du porterar befintlig kod från .NET Framework till .NET Core kan du använda Windows Compatibility Pack. Det ger åtkomst till 20 000 fler API:er än vad som är tillgängligt i .NET Core. Dessa API:er innehåller typer i System.Drawing namnområdet, EventLog klassen, WMI, prestandaräknare, Windows-tjänster och Windows-registertyper och -medlemmar.

Förbättringar av JIT-kompilatorn

.NET Core innehåller en ny JIT-kompilatorteknik som kallas nivåindelad kompilering (kallas även adaptiv optimering) som avsevärt kan förbättra prestandan. Nivåindelad kompilering är en inställning för att välja.

En av de viktiga uppgifter som utförs av JIT-kompilatorn är att optimera kodkörningen. För lite använda kodsökvägar kan kompilatorn dock ägna mer tid åt att optimera kod än körningen av ooptimerad kod. Nivåindelad kompilering introducerar två steg i JIT-kompilering:

  • En första nivå som genererar kod så snabbt som möjligt.

  • En andra nivå, som genererar optimerad kod för de metoder som körs ofta. Den andra nivån av kompilering utförs parallellt för bättre prestanda.

Du kan välja nivåindelad kompilering på något av två sätt.

  • Om du vill använda nivåindelad kompilering i alla projekt som använder .NET Core 2.1 SDK anger du följande miljövariabel:

    COMPlus_TieredCompilation="1"

  • Om du vill använda nivåindelad kompilering per projekt lägger du till <TieredCompilation> egenskapen i <PropertyGroup> avsnittet i MSBuild-projektfilen, som följande exempel visar:

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

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

API-ändringar

Span<T> och Memory<T>

.NET Core 2.1 innehåller några nya typer som gör det mycket effektivare att arbeta med matriser och andra typer av minne. De nya typerna är:

Utan dessa typer måste du, när du skickar sådana objekt som en del av en matris eller ett avsnitt i en minnesbuffert, göra en kopia av en del av data innan du skickar dem till en metod. Dessa typer ger en virtuell vy av dessa data som eliminerar behovet av ytterligare minnesallokering och kopieringsåtgärder.

I följande exempel används en Span<T> instans och Memory<T> för att ge en virtuell vy över 10 element i en matris.

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

.NET Core 2.1 lägger till stöd för Brotli-komprimering och dekomprimering. Brotli är en generell algoritm för förlustfri komprimering som definieras i RFC 7932 och stöds av de flesta webbläsare och större webbservrar. Du kan använda den stream-baserade System.IO.Compression.BrotliStream klassen eller de högpresterande span-baserade System.IO.Compression.BrotliEncoder klasserna och System.IO.Compression.BrotliDecoder klasserna. I följande exempel visas komprimering med BrotliStream klassen:

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

Beteendet BrotliStream är detsamma som DeflateStream och GZipStream, vilket gör det enkelt att konvertera kod som anropar dessa API:er till BrotliStream.

Nya kryptografi-API:er och kryptografiförbättringar

.NET Core 2.1 innehåller många förbättringar av kryptografi-API:erna:

Förbättringar av socketar

.NET Core innehåller en ny typ, System.Net.Http.SocketsHttpHandler, och en omskriven System.Net.Http.HttpMessageHandler, som utgör grunden för nätverks-API:er på högre nivå. System.Net.Http.SocketsHttpHandler, till exempel, är grunden för HttpClient genomförandet. I tidigare versioner av .NET Core baserades API:er på högre nivå på interna nätverksimplementeringar.

Socket-implementeringen som introducerades i .NET Core 2.1 har ett antal fördelar:

  • En betydande prestandaförbättring jämfört med den tidigare implementeringen.

  • Eliminering av plattformsberoenden, vilket förenklar distribution och service.

  • Konsekvent beteende på alla .NET Core-plattformar.

SocketsHttpHandler är standardimplementeringen i .NET Core 2.1. Du kan dock konfigurera programmet så att det använder den äldre HttpClientHandler klassen genom att anropa AppContext.SetSwitch metoden:

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

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

Du kan också använda en miljövariabel för att välja bort att använda socketimplementeringar baserat på SocketsHttpHandler. Om du vill göra detta anger du DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER till antingen false eller 0.

I Windows kan du också välja att använda System.Net.Http.WinHttpHandler, som förlitar sig på en intern implementering eller SocketsHttpHandler klassen genom att skicka en instans av klassen till HttpClient konstruktorn.

I Linux och macOS kan du bara konfigurera HttpClient per process. I Linux måste du distribuera libcurl om du vill använda den gamla HttpClient implementeringen. (Den är installerad med .NET Core 2.0.)

Icke-bakåtkompatibla ändringar

Information om icke-bakåtkompatibla ändringar finns i Icke-bakåtkompatibla ändringar för migrering från version 2.0 till 2.1.

Se även