Co je nového v .NET Core 3.0

Tento článek popisuje, co je v .NET Core 3,0 novinkou. Jedním z největších vylepšení je podpora desktopových aplikací pro Windows (jenom Windows). Pomocí aplikace .NET Core 3,0 SDK desktopové plochy systému Windows můžete přenést model Windows Forms aplikace a Windows Presentation Foundation (WPF). Aby bylo jasné, že je komponenta Desktop systému Windows podporována a je součástí systému Windows. Další informace najdete v části Windows Desktop dále v tomto článku.

.NET Core 3,0 přidává podporu pro C# 8,0. Důrazně doporučujeme používat Visual Studio 2019 verze 16,3 nebo novější, Visual Studio pro Mac 8,3 nebo novější, nebo Visual Studio Code s nejnovějším rozšířením C#.

Stáhněte si a začněte používat .NET Core 3,0 hned teď ve Windows, MacOS nebo Linux.

Další informace o této verzi najdete v tématu oznámení .NET Core 3,0.

.NET Core RC1 se považuje za produkční verzi Microsoft a je plně podporovaná. Pokud používáte verzi Preview, musíte pro pokračování podpory přejít na verzi RTM.

Jazykové vylepšení C# 8,0

C# 8,0 je také součástí této verze, která zahrnuje funkce typu odkazu s možnou hodnotou null , asynchronní datové proudy a další vzory. Další informace o funkcích C# 8,0 naleznete v tématu co je nového v c# 8,0.

Kurzy týkající se funkcí jazyka C# 8,0:

Byla přidána vylepšení jazyka pro podporu následujících funkcí rozhraní API, které jsou popsány níže:

.NET Standard 2,1

.NET Core 3,0 implementuje .NET Standard 2,1. Výchozí dotnet new classlib Šablona však vygeneruje projekt, který je stále cílen .NET Standard 2,0. Chcete-li cílit na .NET Standard 2,1, upravte soubor projektu a změňte TargetFramework vlastnost na netstandard2.1 :

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

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

</Project>

Pokud používáte Visual Studio, budete potřebovat Visual studio 2019, protože Visual Studio 2017 nepodporuje .NET Standard 2,1 nebo .NET Core 3,0.

Kompilovat/nasadit

Výchozí spustitelné soubory

.NET Core teď ve výchozím nastavení vytváří spustitelné soubory závislé na rozhraní . Toto chování je nové u aplikací, které používají globálně nainstalovanou verzi .NET Core. Dříve mohli pouze samostatně nasazená nasazení vyvolat spustitelný soubor.

Během dotnet build nebo se dotnet publish vytvoří spustitelný soubor (známý jako appHost), který odpovídá prostředí a platformě sady SDK, kterou používáte. Pomocí těchto spustitelných souborů můžete očekávat stejné věci jako jiné nativní spustitelné soubory, jako například:

  • Můžete dvakrát kliknout na spustitelný soubor.
  • Aplikaci můžete spustit z příkazového řádku přímo, například myapp.exe ve Windows, a ./myapp v systémech Linux a MacOS.

macOS appHost a notarization

Jenom macOS

Od notarized .NET Core SDK 3,0 pro macOS je nastavení pro vytvoření výchozího spustitelného souboru (známého jako appHost) ve výchozím nastavení zakázané. Další informace najdete v tématu MacOS Catalina notarization a dopad na stažení a projekty .NET Core.

Když je povolené nastavení appHost, .NET Core při sestavování nebo publikování generuje nativní spustitelný soubor strojového souboru. Vaše aplikace běží v kontextu appHost při spuštění ze zdrojového kódu pomocí dotnet run příkazu nebo spuštěním spustitelného souboru stroj-O přímo.

Bez appHost je jediným způsobem, jak může uživatel spustit aplikaci závislou na rozhraní , používat dotnet <filename.dll> příkaz. AppHost se vždy vytvoří při publikování vlastníaplikace.

Můžete buď nakonfigurovat appHost na úrovni projektu, nebo přepnout appHost pro konkrétní dotnet příkaz s -p:UseAppHost parametrem:

  • Soubor projektu

    <PropertyGroup>
      <UseAppHost>true</UseAppHost>
    </PropertyGroup>
    
  • Parametr příkazového řádku

    dotnet run -p:UseAppHost=true
    

Další informace o tomto UseAppHost nastavení najdete v tématu vlastnosti MSBuild pro Microsoft. NET. SDK.

Spustitelné soubory s jedním souborem

dotnet publishPříkaz podporuje balení vaší aplikace do spustitelného souboru specifického pro jednotlivé platformy. Spustitelný soubor je samorozbalovací a obsahuje všechny závislosti (včetně nativních), které jsou nutné ke spuštění vaší aplikace. Při prvním spuštění aplikace se aplikace extrahuje do adresáře na základě názvu aplikace a identifikátoru buildu. Spuštění je rychlejší, když aplikaci znovu spustíte. Pokud se nepoužila nová verze, aplikace se už nebude muset extrahovat druhou dobu.

Chcete-li publikovat soubor s jedním souborem, nastavte PublishSingleFile v projektu nebo na příkazovém řádku pomocí dotnet publish příkazu:

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

-nebo-

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

Další informace o publikování v jednom souboru najdete v dokumentu návrhu sady prostředků s jedním souborem.

Propojení sestavení

Sada .NET Core 3,0 SDK je dodávána s nástrojem, který umožňuje zmenšit velikost aplikací analýzou IL a oříznutím nepoužívaných sestavení.

Samostatné aplikace zahrnují vše potřebné ke spuštění kódu, aniž by bylo nutné nainstalovat rozhraní .NET do hostitelského počítače. Ale hodně, kolikrát aplikace jenom vyžaduje malou podmnožinu rozhraní, a další nepoužívané knihovny by se daly odebrat.

Rozhraní .NET Core nyní obsahuje nastavení, které bude používat nástroj linkeru Il ke kontrole Il vaší aplikace. Tento nástroj zjistí, jaký kód je požadován, a poté ořízne nepoužívané knihovny. Tento nástroj může výrazně zmenšit velikost nasazení některých aplikací.

Pokud chcete tento nástroj povolit, přidejte do projektu nastavení <PublishTrimmed> a publikujte samostatnou aplikaci:

<PropertyGroup>
  <PublishTrimmed>true</PublishTrimmed>
</PropertyGroup>
dotnet publish -r <rid> -c Release

Například základní nová šablona projektu "hello world", která je při publikování zahrnutá, dosáhne velikosti přibližně 70 MB. Použitím příkazu <PublishTrimmed> se tato velikost zmenšuje na přibližně 30 MB.

Je důležité vzít v úvahu, že aplikace nebo architektury (včetně ASP.NET Core a WPF), které používají reflexi nebo související dynamické funkce, se při oříznutém prostředí často přeruší. K tomuto přerušení dochází, protože linker o tomto dynamickém chování neví a nemůže určit, které typy architektur jsou vyžadovány pro reflexi. Nástroj IL Linker je možné nakonfigurovat tak, aby o tomto scénáři věděl.

Nad všemi ostatními je třeba aplikaci otestovat po ořezávání.

Další informace o nástroji IL Linker najdete v dokumentaci nebo v mono/linkeru.

Vrstvené kompilace

Vrstvená kompilace (TC) je ve výchozím nastavení v .NET Core 3.0 povolená. Tato funkce umožňuje modulu runtime adaptivnější použití kompilátoru JIT (Just-in-Time) k dosažení lepšího výkonu.

Hlavní výhodou vrstvené kompilace je poskytnutí dvou způsobů jitování metod: ve vrstvě s nižší kvalitou, ale rychleji nebo ve vrstvě s vyšší kvalitou, ale pomaleji. Kvalita označuje, jak dobře je metoda optimalizovaná. TC pomáhá zlepšit výkon aplikace, protože prochází různými fázemi provádění, od spuštění přes stabilní stav. Pokud je vrstvená kompilace zakázaná, každá metoda se zkompiluje jediným způsobem, který má předsudky ke stabilnímu výkonu při spouštění.

Pokud je povolený příkaz TC, platí následující chování pro kompilaci metody při spuštění aplikace:

  • Pokud má metoda předem zkompilovaný kód nebo ReadyToRun,použije se předem vygenerovaný kód.
  • V opačném případě je metoda jitted. Tyto metody jsou obvykle obecné typy hodnot.
    • Rychlá kompilátor JIT rychleji generuje kvalitní (nebo méně optimalizovaný) kód. V rozhraní .NET Core 3,0 je rychlá technologie JIT standardně povolena pro metody, které neobsahují smyčky a jsou upřednostňovány při spuštění.
    • Plně optimalizovatelný kompilátor JIT vytváří vyšší kvalitu (nebo více optimalizovaného) kódu pomaleji. Pro metody, kde by se nepoužila rychlá JIT (například pokud je metoda s atributem MethodImplOptions.AggressiveOptimization ), se používá plně optimalizující kompilátor JIT.

U často volaných metod kompilátor za běhu nakonec vytvoří plně optimalizovaný kód na pozadí. Optimalizovaný kód pak nahradí předem kompilovaný kód pro danou metodu.

Kód generovaný rychlou JIT může běžet pomaleji, přidělit více paměti nebo použít více místa v zásobníku. V případě problémů můžete vypnout rychlou JIT pomocí této vlastnosti MSBuild v souboru projektu:

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

Chcete-li úplně zakázat použití TC, použijte tuto vlastnost MSBuild v souboru projektu:

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

Tip

Pokud tato nastavení v souboru projektu změníte, může být nutné provést čisté sestavení, aby se nové nastavení projevilo (odstraňte obj bin adresáře a a znovu sestavíte).

Další informace o konfiguraci kompilace v době běhu naleznete v tématu Možnosti konfigurace běhu pro kompilaci.

ReadyToRun image

Můžete zlepšit čas spuštění aplikace .NET Core kompilováním sestavení aplikace jako formátu ReadyToRun (R2R). R2R je forma kompilace v čase před zahájením (AOT).

R2R binární soubory zlepšují výkon při spuštění tím, že snižují množství práce, které kompilátor JIT (just-in-time) potřebuje k tomu, aby se vaše aplikace načítají. Binární soubory obsahují podobný nativní kód v porovnání s tím, co by kompilátor JIT vytvořil. R2R binární soubory jsou však větší, protože obsahují kód pro mezilehlé jazyky (IL), který je stále potřeba pro některé scénáře, a nativní verzi stejného kódu. R2R je k dispozici pouze v případě, že publikujete samostatnou aplikaci, která cílí na konkrétní běhové prostředí (RID), jako je Linux x64 nebo Windows x64.

Chcete-li zkompilovat projekt jako ReadyToRun, postupujte takto:

  1. Přidejte <PublishReadyToRun> nastavení do projektu:

    <PropertyGroup>
      <PublishReadyToRun>true</PublishReadyToRun>
    </PropertyGroup>
    
  2. Publikování samostatné aplikace Tento příkaz například vytvoří samostatnou aplikaci pro 64bitovou verzi Windows:

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

Omezení pro více platforem a architektury

Kompilátor ReadyToRun v současné době nepodporuje křížové cílení. Musíte zkompilovat pro daný cíl. Pokud například chcete image R2R pro Windows x64, musíte v tomto prostředí spustit příkaz publish.

Výjimky křížového cílení:

  • Windows x64 je možné použít ke kompilaci imagí Windows ARM32, ARM64 a x86.
  • Windows x86 je možné použít ke kompilaci imagí Windows ARM32.
  • Linux x64 se používá ke kompilaci imagí ARM32 a ARM64 v Linuxu.

Další informace najdete v tématu Připraveno ke spuštění.

Modul runtime nebo sada SDK

Přeposlání modulu runtime hlavní verze

.NET Core 3.0 zavádí funkci výslovného souhlasu, která vaší aplikaci umožňuje přeposlání k nejnovější hlavní verzi .NET Core. Kromě toho jsme přidali nové nastavení, které řídí, jak se bude u vaší aplikace přeposlání použít. To lze nakonfigurovat následujícími způsoby:

  • Vlastnost souboru projektu: RollForward
  • Vlastnost konfiguračního souboru za běhu: rollForward
  • Proměnná prostředí: DOTNET_ROLL_FORWARD
  • Argument příkazového řádku: --roll-forward

Je nutné zadat jednu z následujících hodnot. Pokud je nastavení vynecháno, je výchozí hodnota podverze .

  • LatestPatch
    Vraťte se k nejvyšší verzi opravy. Tím se zakáže dílčí verze s posunem.
  • Moll
    V případě, že chybí požadovaná dílčí verze, převeďte nahoru na nejnižší nižší verzi. Pokud je k dispozici požadovaná dílčí verze, použije se zásada LatestPatch .
  • Nejdůležitější
    Pokud chybí požadovaná hlavní verze, převeďte ji nahoru na nejnižší nejvyšší hlavní verzi a nejnižší podverzi. Pokud je k dispozici požadovaná hlavní verze, použije se vedlejší zásada.
  • LatestMinor
    Převeďte do nejvyšší dílčí verze, i když je k dispozici požadovaná dílčí verze. Určeno pro scénáře hostování součástí.
  • LatestMajor
    Převeďte do nejvyšší hlavní a nejvyšší dílčí verze, a to i v případě, že je k dispozici požadovaná hlavní verze. Určeno pro scénáře hostování součástí.
  • Dezaktivovat
    Nezadávejte vše. Vytvoří se jenom vazba na určenou verzi. Tato zásada se nedoporučuje pro obecné použití, protože zakazuje přeposílání k nejnovějším opravám. Tato hodnota se doporučuje jenom pro testování.

Kromě nastavení Zakázat budou všechna nastavení používat nejvyšší dostupnou verzi opravy.

Pokud je ve výchozím nastavení požadovaná verze (určená pro aplikaci) verzí, zvažuje se .runtimeconfig.json dopředné přeposlání pouze verze. Všechny předběžné verze se ignorují. Pokud neexistuje žádná odpovídající verze verze, je třeba vzít v úvahu předběžné verze. Toto chování lze změnit nastavením , v DOTNET_ROLL_FORWARD_TO_PRERELEASE=1 takovém případě se vždy zvaží všechny verze.

Sestavení kopíruje závislosti

Příkaz teď zkopíruje závislosti NuGet pro vaši aplikaci z mezipaměti dotnet build NuGet do výstupní složky sestavení. Dříve byly závislosti zkopírovány pouze jako součást dotnet publish .

Existují operace, jako je například odkazování a publikování stránky Razor Page, které bude stále vyžadovat publikování.

Místní nástroje

.NET Core 3.0 zavádí místní nástroje. Místní nástroje se podobají globálním nástrojům, ale jsou přidružené ke konkrétnímu umístění na disku. Místní nástroje nejsou dostupné globálně a distribuují se jako balíčky NuGet.

Upozornění

Pokud jste vyzkoušeli místní nástroje v .NET Core 3.0 Preview 1, například se systémem nebo , odstraňte dotnet tool restore dotnet tool install místní složku mezipaměti nástrojů. V opačném případě nebudou místní nástroje fungovat v žádné novější verzi. Tato složka se nachází v umístění:

V systému macOS v Linuxu: rm -r $HOME/.dotnet/toolResolverCache

Ve Windows: rmdir /s %USERPROFILE%\.dotnet\toolResolverCache

Místní nástroje spoléhají na název souboru manifestu dotnet-tools.json v aktuálním adresáři. Tento soubor manifestu definuje nástroje, které jsou k dispozici v této složce a níže. Můžete distribuovat soubor manifestu s vaším kódem, aby bylo zajištěno, že kdokoli, kdo spolupracuje s vaším kódem, může obnovit a použít stejné nástroje.

U globálních i místních nástrojů se vyžaduje kompatibilní verze modulu runtime. Mnoho nástrojů, které jsou aktuálně na NuGet.org Target pro .NET Core Runtime 2,1. Pokud chcete tyto nástroje nainstalovat globálně nebo lokálně, budete si muset nainstalovat modul runtime .NET Core 2,1.

Nové global.jsmožností

global.jsv souboru obsahuje nové možnosti, které poskytují větší flexibilitu při pokusu o definování používané verze .NET Core SDK. Nové možnosti jsou:

  • allowPrerelease: Určuje, zda má Řešitel sady SDK zvážit předprodejní verze při výběru verze sady SDK, která se má použít.
  • rollForward: Označuje zásadu pro převzetí služeb při obnovení, která se má použít při výběru verze sady SDK, a to buď jako záložní, pokud konkrétní verze sady SDK chybí, nebo jako direktiva pro použití vyšší verze.

Další informace o změnách, včetně výchozích hodnot, podporovaných hodnot a nových pravidel pro porovnání, najdete v tématu global.jspřehledu.

Menší velikosti haldy uvolňování paměti

Výchozí velikost haldy systému uvolňování paměti byla snížena z výsledku rozhraní .NET Core s menším množstvím paměti. Tato změna se lépe zarovnává s rozpočtem přidělení 0. generace s moderními velikostmi mezipaměti procesoru.

Podpora velkokapacitních stránek uvolňování paměti

Velké stránky (označované také jako velké stránky na platformě Linux) jsou funkce, ve které může operační systém vytvořit oblasti paměti větší než velikost nativní stránky (často 4K), aby se zlepšil výkon aplikace požadující tyto velké stránky.

Systém uvolňování paměti se teď dá nakonfigurovat s nastavením GCLargePages jako funkce výslovného souhlasu, která se rozhodne přidělit velké stránky ve Windows.

Windows Desktop & COM

.NET Core SDK Instalační služba systému Windows

Od verze .NET Core 3.0 se instalační program MSI pro Windows změnil. Instalační programy sady SDK teď budou upgradovat verze sady SDK v skupině funkcí. Pásma funkcí jsou definována ve stovkách skupin v části opravy čísla verze. Například 3.0.101 a 3.0.201 jsou verze ve dvou různých pásmech funkcí, zatímco 3.0.101 a 3.0.199 je ve stejné skupině funkcí. A při .NET Core SDK 3.0.Je nainstalovaný 101, .NET Core SDK 3.0.Pokud existuje, odebere se z počítače 100. Když .NET Core SDK 3.0.Na stejném počítači je nainstalovaný 200, .NET Core SDK 3.0.101 se odebere.

Další informace o verzích najdete v tématu Přehled verzí .NET Core.

Plocha Windows

.NET Core 3.0 podporuje desktopové aplikace windows pomocí Windows Presentation Foundation (WPF) a model Windows Forms. Tato rozhraní také podporují použití moderních ovládacích prvků a stylů Fluent z knihovny Windows UI XAML (WinUI) prostřednictvím ostrůvky XAML.

Desktopová komponenta Windows je součástí sady Windows .NET Core 3.0 SDK.

Novou aplikaci WPF nebo model Windows Forms můžete vytvořit pomocí následujících dotnet příkazů:

dotnet new wpf
dotnet new winforms

Visual Studio 2019 přidává nové šablony projektů pro .NET Core 3.0 model Windows Forms a WPF.

Další informace o tom, jak portovat existující aplikaci .NET Framework, najdete v tématu Portování projektů WPF a Port model Windows Forms projekty.

WinForms s vysokým dpi

Aplikace .NET Core model Windows Forms nastavit vysoký režim DPI pomocí Application.SetHighDpiMode(HighDpiMode) . Metoda nastaví odpovídající režim s vysokým dpi, pokud nastavení nebylo nastaveno jinými způsoby, například SetHighDpiMode App.Manifest nebo P/Invoke před Application.Run .

Možné hodnoty highDpiMode vyjádřené System.Windows.Forms.HighDpiMode výčtem jsou:

  • DpiUnaware
  • SystemAware
  • PerMonitor
  • PerMonitorV2
  • DpiUnawareGdiScaled

Další informace o režimech vysokých hodnot DPI najdete v tématu Vývoj desktopových aplikací s vysokým dpi ve Windows.

Vytváření komponent modelu COM

Ve Windows teď můžete vytvářet spravované komponenty volatelné modelem COM. Tato možnost je zásadní pro použití .NET Core s modely doplňku COM a také k zajištění parity s .NET Framework.

Na rozdíl od .NET Framework, kde se mscoree.dll používal jako server com, .NET Core při sestavování komponenty com přidá nativní spouštěcí knihovnu DLL do adresáře bin .

Příklad vytvoření komponenty modelu COM a její využití naleznete v ukázce modelu COM.

Nativní spolupráce Windows

Systém Windows nabízí bohatě nativní rozhraní API ve formě plochých rozhraní API jazyka C, COM a WinRT. I když .NET Core podporuje volání nespravovaného voláním.net Core 3,0, přidává možnost vytvořit rozhraní API modelu COM a aktivovat rozhraní API WinRT. Příklad kódu naleznete v ukázce v aplikaci Excel.

Nasazení MSIX

MSIX je nový formát balíčku aplikace systému Windows. Dá se použít k nasazení desktopových aplikací .NET Core 3,0 do Windows 10.

Projekt pro balení aplikace pro systém Windows, který je k dispozici v aplikaci Visual Studio 2019, umožňuje vytvářet balíčky MSIX pomocí aplikací .NET Core s využitím vlastních součástí .

Soubor projektu .NET Core musí určovat podporované běhové moduly ve <RuntimeIdentifiers> vlastnosti:

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

Vylepšení systému Linux

Portu SerialPort pro Linux

.NET Core 3,0 poskytuje základní podporu pro systém System.IO.Ports.SerialPort Linux.

Dřív se .NET Core podporuje jenom pomocí SerialPort systému Windows.

Další informace o omezené podpoře sériového portu v systému Linux najdete v tématu #33146 problému GitHubu.

Omezení paměti Docker a CGROUP

Provoz .NET Core 3,0 na platformě Linux s Docker funguje lépe s omezeními CGROUP paměti. Spuštění kontejneru Docker s omezeními paměti, jako je například s docker run -m , se změní způsob, jakým se aplikace .NET Core chová.

  • Výchozí velikost haldy uvolňování paměti: maximálně 20 MB nebo 75 % limitu paměti pro kontejner.
  • Explicitní velikost lze nastavit jako absolutní počet nebo procento limitu cgroup.
  • Minimální velikost rezervovaného segmentu na haldu uvolňování paměti je 16 MB. Tato velikost snižuje počet zahod vytvořených na počítačích.

Podpora funkce GPIO pro Raspberry Pi

Do nuGetu byly vydány dva balíčky, které můžete použít pro programování funkce GPIO:

Balíčky GPIO zahrnují rozhraní API pro GPIO, SPI, I2C a PWM zařízení. Balíček vazeb IoT obsahuje vazby zařízení. Další informace najdete v úložišti zařízení na GitHubu.

Podpora ARM64 v Linuxu

.NET Core 3.0 přidává podporu ARM64 pro Linux. Primárním případem použití ARM64 jsou aktuálně scénáře IoT. Další informace najdete v tématu Stav ARM64 v .NET Core.

Image Dockeru pro .NET Core v ARM64 jsou k dispozici pro Alpine, Debian a Ubuntu.

Poznámka

ARM64 Podpora Windows ještě není dostupná.

Zabezpečení

Tls 1.3 & OpenSSL 1.1.1 v Linuxu

.NET Core teď využívá podporu protokolu TLS 1.3 v OpenSSL 1.1.1,pokud je k dispozici v daném prostředí. S protokolem TLS 1.3:

  • Časy připojení se zlepšily s omezenou špičkou odezvy mezi klientem a serverem.
  • Vylepšené zabezpečení kvůli odebrání různých zastaralých a nezabezpečených kryptografických algoritmů.

V případě, že je k dispozici, .NET Core 3,0 používá OpenSSL 1.1.1, OpenSSL 1.1.0 nebo OpenSSL 1.0.2 v systému Linux. Pokud je k dispozici služba OpenSSL 1.1.1 , budou v obou System.Net.Security.SslStream System.Net.Http.HttpClient typech použity protokoly TLS 1,3 (za předpokladu, že klient i server podporují protokol TLS 1,3).

Důležité

Windows a macOS ještě nepodporují TLS 1,3.

Následující příklad C# 8,0 ukazuje rozhraní .NET Core 3,0 na Ubuntu 18,10, které se připojuje k 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}");
        }
    }
}

Kryptografická šifry

.NET Core 3,0 přidává podporu pro šifry AES-GCM a AES-ccm , implementovaná v System.Security.Cryptography.AesGcm a System.Security.Cryptography.AesCcm v uvedeném pořadí. Tyto algoritmy jsou jak ověřené šifrování, tak i algoritmy AEAD (Association data).

Následující kód demonstruje použití AesGcm šifry k šifrování a dešifrování náhodných dat.

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 kryptografického klíče

.NET Core 3,0 podporuje import a export asymetrických veřejných a privátních klíčů ze standardních formátů. Nemusíte používat certifikát X. 509.

Všechny typy klíčů, jako jsou RSA, DSA, ECDSA a ECDiffieHellman, podporují následující formáty:

  • Veřejný klíč

    • X. 509 SubjectPublicKeyInfo
  • Privátní klíč

    • PrivateKeyInfo PKCS # 8
    • EncryptedPrivateKeyInfo PKCS # 8

Klíče RSA podporují i:

  • Veřejný klíč

    • RSAPublicKey PKCS # 1
  • Privátní klíč

    • RSAPrivateKey PKCS # 1

Metody exportu vytvářejí binární data kódovaná DER a metody importu očekávají totéž. Pokud je klíč uložen v textovém formátu PEM, volající bude muset před voláním metody importu dekódovat obsah pomocí metody base64.

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));
        }
    }
}

Soubory PKCS#8 je možné kontrolovat pomocí a soubory System.Security.Cryptography.Pkcs.Pkcs8PrivateKeyInfo PFX/PKCS#12 je možné kontrolovat pomocí System.Security.Cryptography.Pkcs.Pkcs12Info . Se soubory PFX/PKCS#12 lze manipulovat pomocí System.Security.Cryptography.Pkcs.Pkcs12Builder .

Změny rozhraní API .NET Core 3.0

Rozsahy a indexy

Nový System.Index typ lze použít pro indexování. Můžete ho vytvořit z počty od začátku nebo pomocí operátoru int ^ předpony (C#), který počítá od konce:

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"

K dispozici je také typ , který se skládá ze dvou hodnot, jedné pro začátek a jedné pro konec a lze jej zapsat pomocí výrazu rozsahu System.Range Index x..y (C#). Pak můžete indexovat pomocí Range , který vytvoří řez:

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

Další informace najdete v kurzu k rozsahům a indexům.

Asynchronní streamy

Typ IAsyncEnumerable<T> je nová asynchronní verze IEnumerable<T> . Jazyk vám umožňuje využívat jejich prvky a používat je await foreach IAsyncEnumerable<T> k vytvoření yield return prvků.

Následující příklad ukazuje produkci i spotřebu asynchronních datových proudů. Příkaz foreach je asynchronní a sám používá k vytvoření yield return asynchronního datového proudu pro volající. Tento vzor (pomocí yield return ) je doporučený model pro vytváření asynchronních datových proudů.

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

Kromě toho, že je možné , můžete také vytvořit asynchronní iterátory, například iterátor, který vrací , můžete i await foreach IAsyncEnumerable/IAsyncEnumerator v await yield . Pro objekty, které je třeba likvidovat, můžete použít , které implementují různé IAsyncDisposable typy seznamu BCL, například Stream a Timer .

Další informace najdete v kurzu asynchronních datových proudů.

IEEE s plovoucí desetinnou čárkou

Rozhraní API s plovoucí desetinnou čárkou se aktualizují tak, aby odpovídalo revizi IEEE 754-2008. Cílem těchto změn je vystavit všechny požadované operace a zajistit, aby byly vyhovující požadavkům standardu IEEE. Další informace o vylepšeních s plovoucí desetinnou čárkou naleznete v příspěvku na blogu .NET Core 3,0 v oblasti analýzy a formátování plovoucí desetinné čárky.

Mezi aktualizace pro analýzu a formátování patří:

  • Správně Analyzujte a zaokrouhlujte vstupy libovolné délky.
  • Správně Analyzujte a formátujete záporné hodnoty nula.
  • Správně analyzovat Infinity a NaN provést kontrolu bez rozlišení velkých a malých písmen a povolit volitelnou předchozí hodnotu + .

System.MathMezi nová rozhraní API patří:

  • BitIncrement(Double) ani BitDecrement(Double)
    Odpovídá nextUp nextDown operacím IEEE a. Vrátí nejmenší číslo s plovoucí desetinnou čárkou, které porovná větší nebo menší než vstup (v uvedeném pořadí). Například Math.BitIncrement(0.0) vrátí double.Epsilon .

  • MaxMagnitude(Double, Double) ani MinMagnitude(Double, Double)
    Odpovídá maxNumMag minNumMag operacím IEEE a, vrací hodnotu, která je větší nebo menší v rozsahu dvou vstupů (v uvedeném pořadí). Například Math.MaxMagnitude(2.0, -3.0) vrátí -3.0 .

  • ILogB(Double)
    Odpovídá logB operaci IEEE, která vrací celočíselnou hodnotu, vrátí protokol integrálního protokolu Base-2 vstupního parametru. Tato metoda je prakticky stejná jako floor(log2(x)) , ale byla provedena s minimální chybou zaokrouhlení.

  • ScaleB(Double, Int32)
    Odpovídá scaleB operaci IEEE, která přebírá celočíselnou hodnotu, vrátí ji efektivně x * pow(2, n) , ale provede minimální chybu zaokrouhlení.

  • Log2(Double)
    Odpovídá log2 operaci IEEE, vrátí logaritmus o základu 2. Minimalizuje chybu zaokrouhlování.

  • FusedMultiplyAdd(Double, Double, Double)
    Odpovídá fma operaci IEEE, provádí přidaný násobek. To znamená, že (x * y) + z se jedná o jednu operaci, čímž se minimalizuje chyba zaokrouhlení. Příkladem je FusedMultiplyAdd(1e308, 2.0, -1e308) , který vrací 1e308 . Normální vrátí (1e308 * 2.0) - 1e308 double.PositiveInfinity .

  • CopySign(Double, Double)
    Odpovídá operaci copySign IEEE, vrací hodnotu , ale x se znaménkem y .

Vnitřní Platform-Dependent rozhraní .NET

Přidali jsme rozhraní API, která umožňují přístup k určitým instrukcím procesoru orientovaným na výkon, jako jsou například sady instrukcí SIMD nebo Bit Manipulation. Tyto pokyny můžou pomoct dosáhnout výrazného zlepšení výkonu v určitých scénářích, jako je například efektivní paralelní zpracování dat.

V případě potřeby začaly knihovny .NET tyto pokyny používat ke zvýšení výkonu.

Další informace najdete v tématu .NET Platform-Dependent Vnitřní funkce.

Vylepšená rozhraní API verze .NET Core

Počínaje .NET Core 3.0 teď rozhraní API verze, která jsou k dispozici s .NET Core, vrací informace, které očekáváte. Například:

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

Upozornění

Rozbíjení změny. Technicky se jedná o změnu, která je narušující, protože se změnilo schéma verzí.

Rychlá integrovaná podpora JSON

Uživatelé .NET do značné míry spoléhali na Newtonsoft.Jsa další oblíbené knihovny JSON, které jsou i nadále dobrými volbami. Newtonsoft.Json používá řetězce .NET jako svůj základní datový typ, což je UTF-16 pod pokličkou.

Nová integrovaná podpora JSON je vysoce výkonná, nízká přidělení a funguje s textem JSON s kódováním UTF-8. Další informace o oboru System.Text.Json názvů a typech najdete v následujících článcích:

Podpora HTTP/2

System.Net.Http.HttpClientTyp podporuje protokol HTTP/2. Pokud je povolený protokol HTTP/2, vyjednává se verze protokolu HTTP prostřednictvím TLS/ALPN a protokol HTTP/2 se použije, pokud se server rozhodne ho použít.

Výchozí protokol zůstává HTTP/1.1, ale protokol HTTP/2 může být povolen dvěma různými způsoby. Nejdřív můžete nastavit zprávu požadavku HTTP na používání HTTP/2:

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);

Za druhé, HttpClient ve výchozím nastavení se dá změnit na použití HTTP/2:

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);

V mnoha případech, kdy vyvíjíte aplikaci, chcete použít nešifrované připojení. Pokud víte, že cílový koncový bod bude používat protokol HTTP/2, můžete zapnout nezašifrovaná připojení pro HTTP/2. Můžete ji zapnout nastavením DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2UNENCRYPTEDSUPPORT proměnné prostředí na 1 nebo povolením v kontextu aplikace:

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

Další kroky