Nyheter i .NET Core 3.0

Den här artikeln beskriver vad som är nytt i .NET Core 3.0. En av de största förbättringarna är stödet för Windows-skrivbordsprogram (endast Windows). Med hjälp av .NET Core 3.0 SDK-komponenten Windows Desktop kan du porta dina Windows Forms- och Windows Presentation Foundation-program (WPF). För att vara tydlig stöds endast Windows Desktop-komponenten och ingår i Windows. Mer information finns i Avsnittet om Windows-skrivbordet senare i den här artikeln.

.NET Core 3.0 lägger till stöd för C# 8.0. Vi rekommenderar starkt att du använder Visual Studio 2019 version 16.3 eller senare, eller Visual Studio Code med det senaste C#-tillägget.

Ladda ned och kom igång med .NET Core 3.0 just nu i Windows, macOS eller Linux.

Mer information om versionen finns i meddelandet .NET Core 3.0.

.NET Core 3.0 RC 1 ansågs vara produktionsklar av Microsoft och fick fullt stöd. Om du använder en förhandsversion måste du gå över till RTM-versionen för fortsatt support.

Språkförbättringar C# 8.0

C# 8.0 är också en del av den här versionen, som innehåller funktionen för null-referenstyper , asynkrona strömmar och fler mönster. Mer information om C# 8.0-funktioner finns i Nyheter i C# 8.0.

Självstudier relaterade till C# 8.0-språkfunktioner:

• Självstudie: Uttrycka design avsikten tydligare med null- och icke-nullbara referenstyper
• Självstudie: Generera och använda asynkrona strömmar med C# 8.0 och .NET Core 3.0
• Självstudie: Använda mönstermatchning för att skapa typdrivna och datadrivna algoritmer

Språkförbättringar har lagts till för att stödja följande API-funktioner som beskrivs nedan:

• Intervall och index
• Asynkrona strömmar

.NET Standard 2.1

.NET Core 3.0 implementerar .NET Standard 2.1. Standardmallen dotnet new classlib genererar dock ett projekt som fortfarande är avsett för .NET Standard 2.0. Om du vill rikta in dig på .NET Standard 2.1 redigerar du projektfilen och ändrar TargetFramework egenskapen till netstandard2.1:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard2.1</TargetFramework>
  </PropertyGroup>

</Project>

Om du använder Visual Studio behöver du Visual Studio 2019 eftersom Visual Studio 2017 inte stöder .NET Standard 2.1 eller .NET Core 3.0.

Kompilera/distribuera

Körbara standardvärden

.NET Core skapar nu ramverksberoende körbara filer som standard. Det här beteendet är nytt för program som använder en globalt installerad version av .NET Core. Tidigare skulle endast fristående distributioner generera en körbar fil.

Under dotnet build eller dotnet publishskapas en körbar fil (kallas appHost) som matchar miljön och plattformen för den SDK som du använder. Du kan förvänta dig samma saker med dessa körbara filer som andra inbyggda körbara filer, till exempel:

• Du kan dubbelklicka på den körbara filen.
• Du kan starta programmet direkt från en kommandotolk, till exempel myapp.exe i Windows och ./myapp i Linux och macOS.

macOS appHost och notarisering

endast macOS

Från och med den notariserade .NET Core SDK 3.0 för macOS är inställningen för att skapa en körbar standardinställning (kallas appHost) inaktiverad som standard. Mer information finns i macOS Catalina Notarization och påverkan på .NET Core-nedladdningar och projekt.

När appHost-inställningen är aktiverad genererar .NET Core en inbyggd Mach-O-körbar fil när du skapar eller publicerar. Appen körs i kontexten för appHost när den körs från källkoden dotnet run med kommandot eller genom att starta den körbara Mach-O-filen direkt.

Utan appHost är det enda sättet för en användare att starta en ramverksberoende app med dotnet <filename.dll> kommandot . En appHost skapas alltid när du publicerar appen fristående.

Du kan antingen konfigurera appHost på projektnivå eller växla appHost för ett specifikt dotnet kommando med parametern -p:UseAppHost :

• Projektfil

  <PropertyGroup>
    <UseAppHost>true</UseAppHost>
  </PropertyGroup>
  

• Kommandoradsparameter

  dotnet run -p:UseAppHost=true
  

Mer information om inställningen finns i UseAppHost MSBuild-egenskaper för Microsoft.NET.Sdk.

Körbara filer med en fil

Kommandot dotnet publish stöder paketering av din app till en plattformsspecifik körbar fil. Den körbara filen extraheras själv och innehåller alla beroenden (inklusive interna) som krävs för att köra appen. När appen först körs extraheras programmet till en katalog baserat på appnamnet och byggidentifieraren. Start är snabbare när programmet körs igen. Programmet behöver inte extrahera sig själv en andra gång om inte en ny version användes.

Om du vill publicera en körbar fil anger du PublishSingleFile i projektet eller på kommandoraden dotnet publish med kommandot :

<PropertyGroup>
  <RuntimeIdentifier>win10-x64</RuntimeIdentifier>
  <PublishSingleFile>true</PublishSingleFile>
</PropertyGroup>

-eller-

dotnet publish -r win10-x64 -p:PublishSingleFile=true

Mer information om publicering med en fil finns i designdokumentet för en fil.

Trimning av sammansättning

.NET Core 3.0 SDK levereras med ett verktyg som kan minska storleken på appar genom att analysera IL och trimma oanvända sammansättningar.

Fristående appar innehåller allt som behövs för att köra koden, utan att .NET måste installeras på värddatorn. Men många gånger kräver appen bara en liten delmängd av ramverket för att fungera, och andra oanvända bibliotek kan tas bort.

.NET Core innehåller nu en inställning som använder IL Trimmer-verktyget för att genomsöka IL för din app. Det här verktyget identifierar vilken kod som krävs och trimmar sedan oanvända bibliotek. Det här verktyget kan avsevärt minska distributionsstorleken för vissa appar.

Om du vill aktivera det här verktyget lägger du till <PublishTrimmed> inställningen i projektet och publicerar en fristående app:

<PropertyGroup>
  <PublishTrimmed>true</PublishTrimmed>
</PropertyGroup>

dotnet publish -r <rid> -c Release

Till exempel når den grundläggande "hello world" nya konsolprojektmallen som ingår, när den publiceras, cirka 70 MB i storlek. Med hjälp av <PublishTrimmed>minskas den storleken till cirka 30 MB.

Det är viktigt att tänka på att program eller ramverk (inklusive ASP.NET Core och WPF) som använder reflektion eller relaterade dynamiska funktioner ofta bryts när de trimmas. Den här brytningen beror på att trimmern inte känner till det här dynamiska beteendet och inte kan avgöra vilka ramverkstyper som krävs för reflektion. IL Trimmer-verktyget kan konfigureras för att vara medveten om det här scenariot.

Framför allt måste du testa appen efter trimning.

Mer information om IL Trimmer-verktyget finns i dokumentationen eller på lagringsplatsen mono/linker.

Nivåindelad kompilering

Nivåindelad kompilering (TC) är aktiverat som standard med .NET Core 3.0. Den här funktionen gör det möjligt för körningen att mer anpassningsbart använda jit-kompilatorn (just-in-time) för att uppnå bättre prestanda.

Den största fördelen med nivåindelad kompilering är att tillhandahålla två sätt att jittingmetoder: på en nivå med lägre kvalitet men snabbare eller en nivå med högre kvalitet men långsammare. Kvaliteten refererar till hur väl metoden är optimerad. TC hjälper till att förbättra prestanda för ett program när det går igenom olika steg i körningen, från start till stabilt tillstånd. När nivåindelad kompilering är inaktiverad kompileras varje metod på ett enda sätt som är partisk till prestanda i stabilt tillstånd jämfört med startprestanda.

När TC är aktiverat gäller följande beteende för metodkompilering när en app startas:

• Om metoden har kompilerad kod i förväg eller ReadyToRun används den förgenererade koden.
• Annars är metoden jitted. Dessa metoder är vanligtvis generiska över värdetyper.
  • Snabb-JIT genererar kod av lägre kvalitet (eller mindre optimerad) snabbare. I .NET Core 3.0 är Quick JIT aktiverat som standard för metoder som inte innehåller loopar och som föredras under starten.
  • Den fullständigt optimerande JIT-koden ger högre kvalitet (eller mer optimerad) kod långsammare. För metoder där Quick JIT inte skulle användas (till exempel om metoden tillskrivs MethodImplOptions.AggressiveOptimization) används den fullständigt optimerande JIT:en.

För metoder som ofta kallas skapar just-in-time-kompilatorn slutligen helt optimerad kod i bakgrunden. Den optimerade koden ersätter sedan den förkompilerade koden för den metoden.

Kod som genereras av Snabb-JIT kan köras långsammare, allokera mer minne eller använda mer stackutrymme. Om det finns problem kan du inaktivera Snabb-JIT med den här MSBuild-egenskapen i projektfilen:

<PropertyGroup>
  <TieredCompilationQuickJit>false</TieredCompilationQuickJit>
</PropertyGroup>

Om du vill inaktivera TC helt använder du den här MSBuild-egenskapen i projektfilen:

<PropertyGroup>
  <TieredCompilation>false</TieredCompilation>
</PropertyGroup>

Dricks

Om du ändrar de här inställningarna i projektfilen kan du behöva utföra en ren version för att de nya inställningarna ska återspeglas (ta bort obj katalogerna och bin återskapa).

Mer information om hur du konfigurerar kompilering vid körning finns i Körningskonfigurationsalternativ för kompilering.

ReadyToRun-avbildningar

Du kan förbättra starttiden för ditt .NET Core-program genom att kompilera programsammansättningarna som ReadyToRun-format (R2R). R2R är en form av AOT-kompilering (ahead-of-time).

R2R-binärfiler förbättrar startprestanda genom att minska mängden arbete som jit-kompilatorn (just-in-time) behöver utföra när programmet läses in. Binärfilerna innehåller liknande intern kod jämfört med vad JIT skulle generera. R2R-binärfiler är dock större eftersom de innehåller både mellanliggande språkkod (IL), som fortfarande behövs för vissa scenarier och den interna versionen av samma kod. R2R är endast tillgängligt när du publicerar en fristående app som riktar sig till specifika körningsmiljöer (RID), till exempel Linux x64 eller Windows x64.

Kompilera projektet som ReadyToRun genom att göra följande:

1. Lägg till inställningen i <PublishReadyToRun> projektet:

   <PropertyGroup>
     <PublishReadyToRun>true</PublishReadyToRun>
   </PropertyGroup>
   

2. Publicera en fristående app. Det här kommandot skapar till exempel en fristående app för 64-bitarsversionen av Windows:

   dotnet publish -c Release -r win-x64 --self-contained
   

Begränsningar för plattformsoberoende/arkitektur

ReadyToRun-kompilatorn stöder för närvarande inte korsmål. Du måste kompilera på ett visst mål. Om du till exempel vill ha R2R-avbildningar för Windows x64 måste du köra publiceringskommandot i den miljön.

Undantag för korsmål:

• Windows x64 kan användas för att kompilera Windows Arm32-, Arm64- och x86-avbildningar.
• Windows x86 kan användas för att kompilera Windows Arm32-avbildningar.
• Linux x64 kan användas för att kompilera Linux Arm32- och Arm64-avbildningar.

Mer information finns i Redo att köras.

Runtime/SDK

Körningsförlopp i högre version framåt

.NET Core 3.0 introducerar en opt-in-funktion som gör att din app kan rulla vidare till den senaste huvudversionen av .NET Core. Dessutom har en ny inställning lagts till för att styra hur vidarekoppling tillämpas på din app. Detta kan konfigureras på följande sätt:

• Projektfilegenskap: RollForward
• Körningskonfigurationsfilegenskap: rollForward
• Miljövariabel: DOTNET_ROLL_FORWARD
• Kommandoradsargument: --roll-forward

Ett av följande värden måste anges. Om inställningen utelämnas är Minor standardvärdet.

• LatestPatch
  Rulla vidare till den högsta korrigeringsversionen. Detta inaktiverar delversionsfördrullning framåt.
• Underårig
  Rulla vidare till den lägsta lägre delversionen om den begärda delversionen saknas. Om den begärda delversionen finns används LatestPatch-principen .
• Major
  Rulla vidare till den lägsta högre huvudversionen och den lägsta delversionen om den begärda huvudversionen saknas. Om den begärda huvudversionen finns används delprincipen.
• LatestMinor
  Rulla vidare till högsta delversion, även om den begärda delversionen finns. Avsedd för scenarier för komponentvärdar.
• SenasteMajor
  Rulla vidare till högsta högre och högsta delversion, även om den begärda huvudversionen finns. Avsedd för scenarier för komponentvärdar.
• Inaktivera
  Rulla inte framåt. Bind endast till angiven version. Den här principen rekommenderas inte för allmän användning eftersom den inaktiverar möjligheten att rulla vidare till de senaste korrigeringarna. Det här värdet rekommenderas endast för testning.

Förutom inställningen Inaktivera använder alla inställningar den högsta tillgängliga korrigeringsversionen.

Om den begärda versionen (som anges i .runtimeconfig.json för programmet) som standard är en versionsversion beaktas endast versionsversioner för vidarekoppling. Alla förhandsversioner ignoreras. Om det inte finns någon matchande versionsversion beaktas förhandsversioner. Det här beteendet kan ändras genom att ange DOTNET_ROLL_FORWARD_TO_PRERELEASE=1, i vilket fall alla versioner alltid beaktas.

Skapa kopior av beroenden

Kommandot dotnet build kopierar nu NuGet-beroenden för ditt program från NuGet-cachen till utdatamappen build. Tidigare kopierades beroenden endast som en del av dotnet publish.

Det finns vissa åtgärder, till exempel trimning och razor-sidpublicering, som fortfarande kräver publicering.

Lokala verktyg

.NET Core 3.0 introducerar lokala verktyg. Lokala verktyg liknar globala verktyg men är associerade med en viss plats på disken. Lokala verktyg är inte tillgängliga globalt och distribueras som NuGet-paket.

Lokala verktyg förlitar sig på ett manifestfilnamn dotnet-tools.json i den aktuella katalogen. Den här manifestfilen definierar vilka verktyg som ska vara tillgängliga i den mappen och nedan. Du kan distribuera manifestfilen med koden för att se till att alla som arbetar med koden kan återställa och använda samma verktyg.

För både globala och lokala verktyg krävs en kompatibel version av körningen. För närvarande finns det många verktyg på NuGet.org .NET Core Runtime 2.1 som mål. Om du vill installera dessa verktyg globalt eller lokalt behöver du fortfarande installera NET Core 2.1-körningen.

Nya alternativ för global.json

Filen global.json har nya alternativ som ger större flexibilitet när du försöker definiera vilken version av .NET Core SDK som används. De nya alternativen är:

• allowPrerelease: Anger om SDK-matcharen ska överväga förhandsversioner när du väljer den SDK-version som ska användas.
• rollForward: Anger den framåtrullningsprincip som ska användas när du väljer en SDK-version, antingen som reserv när en specifik SDK-version saknas eller som ett direktiv om att använda en högre version.

Mer information om ändringar som standardvärden, värden som stöds och nya matchningsregler finns i global.json översikt.

Mindre heapstorlekar för skräpinsamling

Skräpinsamlarens standard heapstorlek har minskats vilket resulterar i att .NET Core använder mindre minne. Den här ändringen överensstämmer bättre med allokeringsbudgeten för generation 0 med moderna processorcachestorlekar.

Stöd för stora sidor för skräpinsamling

Stora sidor (även kallat Enorma sidor i Linux) är en funktion där operativsystemet kan upprätta minnesregioner som är större än den ursprungliga sidstorleken (ofta 4 000) för att förbättra prestandan för programmet som begär dessa stora sidor.

Skräpinsamlaren kan nu konfigureras med inställningen GCLargePages som en funktion för att välja att allokera stora sidor i Windows.

Windows Desktop och COM

.NET Core SDK Windows Installer

MSI-installationsprogrammet för Windows har ändrats från och med .NET Core 3.0. SDK-installationsprogrammet uppgraderar nu SDK-funktionsbandsversioner på plats. Funktionsband definieras i hundratals grupper i korrigeringsavsnittet i versionsnumret. Till exempel 3.0.101 och 3.0.201 är versioner i två olika funktionsband medan 3.0.101 och 3.0.199 är i samma funktionsband. Och när .NET Core SDK 3.0.101 är installerat, .NET Core SDK 3.0.100 tas bort från datorn om den finns. När .NET Core SDK 3.0.200 är installerat på samma dator, .NET Core SDK 3.0.101 tas inte bort.

Mer information om versionshantering finns i Översikt över hur .NET Core är version.

Windows-skrivbordet

.NET Core 3.0 stöder Windows-skrivbordsprogram med hjälp av Windows Presentation Foundation (WPF) och Windows Forms. Dessa ramverk stöder också användning av moderna kontroller och Fluent-formatering från Windows UI XAML Library (WinUI) via XAML-öar.

Windows Desktop-komponenten är en del av Windows .NET Core 3.0 SDK.

Du kan skapa en ny WPF- eller Windows Forms-app med följande dotnet kommandon:

dotnet new wpf
dotnet new winforms

Visual Studio 2019 lägger till nya projektmallar för .NET Core 3.0 Windows Forms och WPF.

Mer information om hur du porterar ett befintligt .NET Framework-program finns i Port WPF-projekt och Port Windows Forms-projekt.

WinForms hög DPI

.NET Core Windows Forms-program kan ange högt DPI-läge med Application.SetHighDpiMode(HighDpiMode). Metoden SetHighDpiMode anger motsvarande höga DPI-läge såvida inte inställningen har angetts på annat sätt som App.Manifest eller P/Invoke före Application.Run.

De möjliga highDpiMode värdena, som uttrycks av System.Windows.Forms.HighDpiMode uppräkningen, är:

• DpiUnaware
• SystemAware
• PerMonitor
• PerMonitorV2
• DpiUnawareGdiScaled

Mer information om höga DPI-lägen finns i Programutveckling för hög DPI Desktop i Windows.

Skapa COM-komponenter

I Windows kan du nu skapa COM-anropbara hanterade komponenter. Den här funktionen är viktig för att använda .NET Core med COM-tilläggsmodeller och även för att ge paritet med .NET Framework.

Till skillnad från .NET Framework där mscoree.dll användes som COM-server lägger .NET Core till en inbyggd startdll i bin-katalogen när du skapar DIN COM-komponent.

Ett exempel på hur du skapar en COM-komponent och använder den finns i COM-demonstrationen.

Windows Native Interop

Windows erbjuder ett omfattande internt API i form av platta C-API:er, COM och WinRT. Även om .NET Core stöder P/Invoke lägger .NET Core 3.0 till möjligheten att skapa COM-API:er och aktivera WinRT-API:er. Ett kodexempel finns i Excel Demo.

MSIX-distribution

MSIX är ett nytt Windows-programpaketformat. Den kan användas för att distribuera .NET Core 3.0-skrivbordsprogram till Windows 10.

Med Windows Application Packaging Project, som finns i Visual Studio 2019, kan du skapa MSIX-paket med fristående .NET Core-program.

.NET Core-projektfilen måste ange vilka körningskörningar som stöds i <RuntimeIdentifiers> egenskapen:

<RuntimeIdentifiers>win-x86;win-x64</RuntimeIdentifiers>

Linux-förbättringar

SerialPort för Linux

.NET Core 3.0 ger grundläggande stöd för System.IO.Ports.SerialPort i Linux.

Tidigare har .NET Core endast stöd för användning i SerialPort Windows.

Mer information om det begränsade stödet för serieporten i Linux finns i GitHub-problem #33146.

Minnesgränser för Docker och cgroup

Att köra .NET Core 3.0 på Linux med Docker fungerar bättre med cgroup-minnesgränser. Om du kör en Docker-container med minnesgränser, till exempel med docker run -m, ändras hur .NET Core beter sig.

• Standardstorlek för skräpinsamlare (GC): högst 20 mb eller 75 % av minnesgränsen för containern.
• Explicit storlek kan anges som ett absolut tal eller en procentandel av cgroup-gränsen.
• Minsta reserverade segmentstorlek per GC-heap är 16 mb. Den här storleken minskar antalet heaps som skapas på datorer.

GPIO-stöd för Raspberry Pi

Två paket har släppts till NuGet som du kan använda för GPIO-programmering:

• System.Device.Gpio
• Iot.Device.Bindings

GPIO-paketen innehåller API:er för GPIO-, SPI-, I2C- och PWM-enheter . IoT-bindningspaketet innehåller enhetsbindningar. Mer information finns i GitHub-lagringsplatsen för enheter.

Stöd för Arm64 Linux

.NET Core 3.0 lägger till stöd för Arm64 för Linux. Det primära användningsfallet för Arm64 är för närvarande med IoT-scenarier. Mer information finns i .NET Core Arm64 Status.

Docker-avbildningar för .NET Core på Arm64 är tillgängliga för Alpine, Debian och Ubuntu.

Kommentar

Stöd för operativsystemen macOS Arm64 (eller "Apple Silicon") och Windows Arm64 lades senare till i .NET 6.

Säkerhet

TLS 1.3 & OpenSSL 1.1.1 på Linux

.NET Core drar nu nytta av TLS 1.3-stöd i OpenSSL 1.1.1 när det är tillgängligt i en viss miljö. Med TLS 1.3:

• Anslutningstiderna förbättras med minskade tur- och returresor som krävs mellan klienten och servern.
• Förbättrad säkerhet på grund av borttagning av olika föråldrade och osäkra kryptografiska algoritmer.

När det är tillgängligt använder .NET Core 3.0 OpenSSL 1.1.1, OpenSSL 1.1.0 eller OpenSSL 1.0.2 på ett Linux-system. När OpenSSL 1.1.1 är tillgängligt använder båda System.Net.Http.HttpClient System.Net.Security.SslStream typerna TLS 1.3 (förutsatt att både klienten och servern stöder TLS 1.3).

Följande C# 8.0-exempel visar .NET Core 3.0 på Ubuntu 18.10 som ansluter till https://www.cloudflare.com:

using System;
using System.Net.Security;
using System.Net.Sockets;
using System.Threading.Tasks;

namespace whats_new
{
    public static class TLS
    {
        public static async Task ConnectCloudFlare()
        {
            var targetHost = "www.cloudflare.com";

            using TcpClient tcpClient = new TcpClient();

            await tcpClient.ConnectAsync(targetHost, 443);

            using SslStream sslStream = new SslStream(tcpClient.GetStream());

            await sslStream.AuthenticateAsClientAsync(targetHost);
            await Console.Out.WriteLineAsync($"Connected to {targetHost} with {sslStream.SslProtocol}");
        }
    }
}

Kryptografi chiffer

.NET Core 3.0 lägger till stöd för AES-GCM- och AES-CCM-chiffer, implementerade med System.Security.Cryptography.AesCcm System.Security.Cryptography.AesGcm respektive. Dessa algoritmer är båda Autentiserad kryptering med AEAD-algoritmer (Association Data).

Följande kod visar hur du använder AesGcm chiffer för att kryptera och dekryptera slumpmässiga data.

using System;
using System.Linq;
using System.Security.Cryptography;

namespace whats_new
{
    public static class Cipher
    {
        public static void Run()
        {
            // key should be: pre-known, derived, or transported via another channel, such as RSA encryption
            byte[] key = new byte[16];
            RandomNumberGenerator.Fill(key);

            byte[] nonce = new byte[12];
            RandomNumberGenerator.Fill(nonce);

            // normally this would be your data
            byte[] dataToEncrypt = new byte[1234];
            byte[] associatedData = new byte[333];
            RandomNumberGenerator.Fill(dataToEncrypt);
            RandomNumberGenerator.Fill(associatedData);

            // these will be filled during the encryption
            byte[] tag = new byte[16];
            byte[] ciphertext = new byte[dataToEncrypt.Length];

            using (AesGcm aesGcm = new AesGcm(key))
            {
                aesGcm.Encrypt(nonce, dataToEncrypt, ciphertext, tag, associatedData);
            }

            // tag, nonce, ciphertext, associatedData should be sent to the other part

            byte[] decryptedData = new byte[ciphertext.Length];

            using (AesGcm aesGcm = new AesGcm(key))
            {
                aesGcm.Decrypt(nonce, ciphertext, tag, decryptedData, associatedData);
            }

            // do something with the data
            // this should always print that data is the same
            Console.WriteLine($"AES-GCM: Decrypted data is {(dataToEncrypt.SequenceEqual(decryptedData) ? "the same as" : "different than")} original data.");
        }
    }
}

Import/export av kryptografisk nyckel

.NET Core 3.0 stöder import och export av asymmetriska offentliga och privata nycklar från standardformat. Du behöver inte använda ett X.509-certifikat.

Alla nyckeltyper, till exempel RSA, DSA, ECDsa och ECDiffieHellman, stöder följande format:

• Offentlig nyckel

  • X.509 SubjectPublicKeyInfo

• Privat nyckel

  • PKCS#8 PrivateKeyInfo
  • PKCS#8 EncryptedPrivateKeyInfo

RSA-nycklar stöder också:

• Offentlig nyckel

  • PKCS#1 RSAPublicKey

• Privat nyckel

  • PKCS#1 RSAPrivateKey

Exportmetoderna producerar DER-kodade binära data och importmetoderna förväntar sig samma sak. Om en nyckel lagras i textvänligt PEM-format måste anroparen base64-avkoda innehållet innan en importmetod anropas.

using System;
using System.Security.Cryptography;

namespace whats_new
{
    public static class RSATest
    {
        public static void Run(string keyFile)
        {
            using var rsa = RSA.Create();

            byte[] keyBytes = System.IO.File.ReadAllBytes(keyFile);
            rsa.ImportRSAPrivateKey(keyBytes, out int bytesRead);

            Console.WriteLine($"Read {bytesRead} bytes, {keyBytes.Length - bytesRead} extra byte(s) in file.");
            RSAParameters rsaParameters = rsa.ExportParameters(true);
            Console.WriteLine(BitConverter.ToString(rsaParameters.D));
        }
    }
}

PKCS#8-filer kan inspekteras med System.Security.Cryptography.Pkcs.Pkcs8PrivateKeyInfo och PFX/PKCS#12-filer kan inspekteras med System.Security.Cryptography.Pkcs.Pkcs12Info. PFX/PKCS#12-filer kan manipuleras med System.Security.Cryptography.Pkcs.Pkcs12Builder.

.NET Core 3.0 API-ändringar

Intervall och index

Den nya System.Index typen kan användas för indexering. Du kan skapa en från en int som räknas från början eller med en prefixoperator ^ (C#) som räknas från slutet:

Index i1 = 3;  // number 3 from beginning
Index i2 = ^4; // number 4 from end
int[] a = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
Console.WriteLine($"{a[i1]}, {a[i2]}"); // "3, 6"

Det finns också typen System.Range , som består av två Index värden, ett för start och ett för slutet, och kan skrivas med ett x..y intervalluttryck (C#). Du kan sedan indexera med en Range, som skapar en sektor:

var slice = a[i1..i2]; // { 3, 4, 5 }

Mer information finns i självstudiekursen om intervall och index.

Asynkrona strömmar

Typen IAsyncEnumerable<T> är en ny asynkron version av IEnumerable<T>. Med språket kan du await foreach IAsyncEnumerable<T> använda elementen och använda yield return dem för att skapa element.

I följande exempel visas både produktion och förbrukning av asynkrona strömmar. -instruktionen foreach är asynkron och används yield return för att skapa en asynkron ström för anropare. Det här mönstret (med hjälp av yield return) är den rekommenderade modellen för att producera asynkrona strömmar.

async IAsyncEnumerable<int> GetBigResultsAsync()
{
    await foreach (var result in GetResultsAsync())
    {
        if (result > 20) yield return result;
    }
}

Förutom att await foreachkunna kan kan du även skapa asynkrona iteratorer, till exempel en iterator som returnerar en IAsyncEnumerable/IAsyncEnumerator som du kan både await och yield i. För objekt som måste tas bort kan du använda IAsyncDisposable, som olika BCL-typer implementerar, till exempel Stream och Timer.

Mer information finns i självstudien om asynkrona strömmar.

Flyttal för IEEE

API:er för flyttals uppdateras för att följa IEEE 754-2008-revisionen. Målet med dessa ändringar är att exponera alla nödvändiga åtgärder och se till att de är beteendemässigt kompatibla med IEEE-specifikationen. Mer information om förbättringar av flyttalser finns i förbättringarna flyttalsparsing och formatering i blogginlägget .NET Core 3.0 .

Parsnings- och formateringskorrigeringar omfattar:

• Korrekt parsa och runda indata av valfri längd.
• Parsa och formatera negativ nolla korrekt.
• Parsa Infinity korrekt och NaN genom att göra en skiftlägesokänslig kontroll och tillåta ett valfritt föregående i förekommande + fall.

Nya System.Math API:er är:

• BitIncrement(Double) och BitDecrement(Double)
  nextUp Motsvarar IEEE-åtgärderna och nextDown . De returnerar det minsta flyttalsnumret som jämför större eller mindre än indata (respektive). Skulle till exempel Math.BitIncrement(0.0) returnera double.Epsilon.

• MaxMagnitude(Double, Double) och MinMagnitude(Double, Double)
  Motsvarar IEEE-åtgärderna och minNumMag returnerar maxNumMag värdet som är större eller mindre i storlek för de två indata (respektive). Skulle till exempel Math.MaxMagnitude(2.0, -3.0) returnera -3.0.

• ILogB(Double)
  Motsvarar den logB IEEE-åtgärd som returnerar ett integralvärde, returnerar den integral base-2-loggen för indataparametern. Den här metoden är i praktiken samma som floor(log2(x)), men utförs med minimalt avrundningsfel.

• ScaleB(Double, Int32)
  Motsvarar IEEE-åtgärden scaleB som tar ett integralvärde, den returnerar effektivt x * pow(2, n), men görs med minimalt avrundningsfel.

• Log2(Double)
  log2 Motsvarar IEEE-åtgärden, returnerar den base-2 logaritmen. Det minimerar avrundningsfel.

• FusedMultiplyAdd(Double, Double, Double)
  Motsvarar IEEE-åtgärden fma utför den ett sammansvetsat multiplikationstillägg. Det innebär att den gör (x * y) + z det som en enda åtgärd, vilket minimerar avrundningsfelet. Ett exempel är FusedMultiplyAdd(1e308, 2.0, -1e308), som returnerar 1e308. Den vanliga (1e308 * 2.0) - 1e308 returnerar double.PositiveInfinity.

• CopySign(Double, Double)
  Motsvarar IEEE-åtgärden returnerar copySign den värdet xför , men med tecknet y.

.NET Platform-Dependent Intrinsics

API:er har lagts till som tillåter åtkomst till vissa perf-orienterade CPU-instruktioner, till exempel SIMD - eller Bit Manipulation-instruktionsuppsättningar . De här instruktionerna kan hjälpa dig att uppnå betydande prestandaförbättringar i vissa scenarier, till exempel att bearbeta data effektivt parallellt.

I förekommande fall har .NET-biblioteken börjat använda dessa instruktioner för att förbättra prestandan.

Mer information finns i .NET Platform-Dependent Intrinsics.

Förbättrade API:er för .NET Core-version

Från och med .NET Core 3.0 returnerar de version-API:er som tillhandahålls med .NET Core nu den information du förväntar dig. Till exempel:

System.Console.WriteLine($"Environment.Version: {System.Environment.Version}");

// Old result
//   Environment.Version: 4.0.30319.42000
//
// New result
//   Environment.Version: 3.0.0

System.Console.WriteLine($"RuntimeInformation.FrameworkDescription: {System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription}");

// Old result
//   RuntimeInformation.FrameworkDescription: .NET Core 4.6.27415.71
//
// New result (notice the value includes any preview release information)
//   RuntimeInformation.FrameworkDescription: .NET Core 3.0.0-preview4-27615-11

Varning

Icke-bakåtkompatibel ändring. Detta är tekniskt sett en icke-bakåtkompatibel ändring eftersom versionsschemat har ändrats.

Snabbt inbyggt JSON-stöd

.NET-användare har till stor del förlitat sig på Newtonsoft.Json och andra populära JSON-bibliotek, som fortsätter att vara bra val. Newtonsoft.Json använder .NET-strängar som basdatatyp, som är UTF-16 under huven.

Det nya inbyggda JSON-stödet är högpresterande, låg allokering och fungerar med UTF-8-kodad JSON-text. Mer information om System.Text.Json namnområdet och typerna finns i följande artiklar:

• JSON-serialisering i .NET – översikt
• Serialisera och deserialisera JSON i .NET.
• Migrera från Newtonsoft.Json till System.Text.Json

Stöd för HTTP/2

Typen System.Net.Http.HttpClient stöder HTTP/2-protokollet. Om HTTP/2 är aktiverat förhandlas HTTP-protokollversionen via TLS/ALPN och HTTP/2 används om servern väljer att använda den.

Standardprotokollet förblir HTTP/1.1, men HTTP/2 kan aktiveras på två olika sätt. Först kan du ange HTTP-begärandemeddelandet så att HTTP/2 används:

var client = new HttpClient() { BaseAddress = new Uri("https://localhost:5001") };

// HTTP/1.1 request
using (var response = await client.GetAsync("/"))
    Console.WriteLine(response.Content);

// HTTP/2 request
using (var request = new HttpRequestMessage(HttpMethod.Get, "/") { Version = new Version(2, 0) })
using (var response = await client.SendAsync(request))
    Console.WriteLine(response.Content);

För det andra kan du ändra HttpClient till att använda HTTP/2 som standard:

var client = new HttpClient()
{
    BaseAddress = new Uri("https://localhost:5001"),
    DefaultRequestVersion = new Version(2, 0)
};

// HTTP/2 is default
using (var response = await client.GetAsync("/"))
    Console.WriteLine(response.Content);

Många gånger när du utvecklar ett program vill du använda en okrypterad anslutning. Om du vet att målslutpunkten använder HTTP/2 kan du aktivera okrypterade anslutningar för HTTP/2. Du kan aktivera den genom att ange DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2UNENCRYPTEDSUPPORT miljövariabeln till eller genom att 1 aktivera den i appkontexten:

AppContext.SetSwitch("System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", true);

Nästa steg

• Granska de icke-bakåtkompatibla ändringarna mellan .NET Core 2.2 och 3.0.
• Granska de icke-bakåtkompatibla ändringarna i .NET Core 3.0 för Windows Forms-appar.