Co je nového v .NET Core 3.0

Tento článek popisuje, co je nového v .NET Core 3.0. Jedním z největších vylepšení je podpora desktopových aplikací pro Windows (jenom Windows). Pomocí komponenty .NET Core 3.0 SDK pro Windows Desktop můžete přenést aplikace model Windows Forms a WPF (Windows Presentation Foundation). Aby bylo jasné, je komponenta Windows Desktop podporována a zahrnuta pouze ve Windows. Další informace najdete v části Plocha systému Windows 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ší nebo Visual Studio Code s nejnovějším rozšířením jazyka C#.

Stáhněte si a začněte s .NET Core 3.0 právě teď ve Windows, macOS nebo Linuxu.

Další informace o vydání najdete v oznámení .NET Core 3.0.

Platforma .NET Core 3.0 RC 1 byla považována za produkční prostředí připravená společností Microsoft a byla plně podporována. Pokud používáte verzi Preview, musíte přejít na verzi RTM, abyste mohli pokračovat v podpoře.

Vylepšení jazyka C# 8.0

C# 8.0 je také součástí této verze, která zahrnuje funkci referenčních typů s možnou hodnotou null, asynchronní streamy a další vzory. Další informace o funkcích C# 8.0 najdete v tématu Co je nového v jazyce C# 8.0.

Kurzy související s funkcemi jazyka C# 8.0:

• Kurz: Přehlednější vyjádření záměru návrhu s odkazovými typy s možnou hodnotou null a nenulovou hodnotou
• Kurz: Generování a využívání asynchronních streamů pomocí C# 8.0 a .NET Core 3.0
• Kurz: Použití porovnávání vzorů k vytváření algoritmů řízených typem a datových řízených algoritmy

Byla přidána vylepšení jazyka pro podporu následujících funkcí rozhraní API podrobně popsaných níže:

• Rozsahy a indexy
• Asynchronní streamy

.NET Standard 2.1

.NET Core 3.0 implementuje .NET Standard 2.1. Výchozí dotnet new classlib šablona však vygeneruje projekt, který stále cílí na .NET Standard 2.0. Pokud chcete 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, potřebujete Visual Studio 2019, protože Visual Studio 2017 nepodporuje .NET Standard 2.1 ani .NET Core 3.0.

Kompilace nebo nasazení

Výchozí spustitelné soubory

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

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

• Poklikejte na spustitelný soubor.
• Aplikaci můžete spustit přímo z příkazového řádku, například myapp.exe ve Windows a ./myapp v Linuxu a macOS.

macOS appHost a notarizace

Jenom macOS

Od notářské sady .NET Core SDK 3.0 pro macOS je ve výchozím nastavení zakázané nastavení pro vytvoření výchozího spustitelného souboru (označovaného jako appHost). Další informace najdete v článku macOS Catalina Notarization a dopad na stahování a projekty .NET Core.

Pokud je nastavení appHost povolené, .NET Core při sestavování nebo publikování generuje nativní spustitelný soubor Mach-O. 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 Mach-O přímo.

Bez appHost, jediný způsob, jak uživatel může spustit aplikaci závislá na rozhraní, je s příkazem dotnet <filename.dll> . Hostitel aplikace se vždy vytvoří, když publikujete aplikaci samostatně.

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

• Soubor projektu

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

• Parametr příkazového řádku

  dotnet run -p:UseAppHost=true
  

Další informace o UseAppHost nastavení naleznete v tématu MSBuild vlastnosti pro Microsoft.NET.Sdk.

Spustitelné soubory s jedním souborem

Příkaz dotnet publish podporuje zabalení aplikace do spustitelného souboru specifického pro platformu. Spustitelný soubor se sám extrahuje a obsahuje všechny závislosti (včetně nativních), které jsou potřeba 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 sestavení. Po opětovném spuštění aplikace je spuštění rychlejší. Aplikace se nemusí extrahovat podruhé, pokud nebyla použita nová verze.

Pokud chcete publikovat spustitelný soubor s jedním souborem, nastavte ho PublishSingleFile v projektu nebo na příkazovém dotnet publish řádku pomocí 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í s jedním souborem najdete v návrhovém dokumentu s jedním souborem bundleru.

Oříznutí sestavení

Sada .NET Core 3.0 SDK obsahuje nástroj, který dokáže zmenšit velikost aplikací analýzou IL a oříznutím nepoužívaných sestavení.

Součástí samostatných aplikací je vše potřebné ke spuštění kódu, aniž by bylo nutné nainstalovat rozhraní .NET do hostitelského počítače. Aplikace ale často vyžaduje pouze malou podmnožinu architektury, která funguje, a jiné nepoužívané knihovny je možné odebrat.

.NET Core teď obsahuje nastavení, které použije nástroj IL Trimmer ke kontrole IL aplikace. Tento nástroj zjistí, jaký kód je potřeba, a pak oříznou nepoužívané knihovny. Tento nástroj může výrazně snížit velikost nasazení některých aplikací.

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

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

dotnet publish -r <rid> -c Release

Například základní šablona nového projektu "hello world" zahrnutá při publikování dosáhne velikosti přibližně 70 MB. <PublishTrimmed>Použitím této velikosti se zmenší na přibližně 30 MB.

Je důležité zvážit, ž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í často přeruší. K tomuto přerušení dochází, protože zatřižovač o tomto dynamickém chování neví a nemůže určit, které typy rozhraní jsou potřeba pro reflexi. Nástroj IL Trimmer je možné nakonfigurovat tak, aby o tomto scénáři věděl.

Než všechno ostatní, nezapomeňte po oříznutí otestovat aplikaci.

Další informace o nástroji IL Trimmer naleznete v dokumentaci nebo navštivte úložiště mono/linker.

Vrstvené kompilace

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

Hlavní výhodou vrstvené kompilace je poskytnout dva způsoby zápisu metod: v nižší kvalitě, ale rychlejší vrstvě nebo vyšší kvalitě, ale pomalejší vrstvě. Kvalita odkazuje na to, 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. Při zakázání vrstvené kompilace se každá metoda zkompiluje jedním způsobem, který je zkreslený na výkon stabilního stavu oproti výkonu při spuštění.

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

• Pokud má metoda předem zkompilovaný kód nebo ReadyToRun, použije se předgenerovaný kód.
• V opačném případě je metoda zaměněná. Tyto metody jsou obvykle obecné typy hodnot.
  • Quick JIT vytváří kód s nižší kvalitou (nebo méně optimalizovaným) rychleji. V .NET Core 3.0 je funkce Quick JIT ve výchozím nastavení povolená pro metody, které neobsahují smyčky a jsou upřednostňované při spuštění.
  • Plně optimalizující JIT vytváří kód s vyšší kvalitou (nebo více optimalizovaným) pomaleji. Pro metody, ve kterých by se rychlý JIT nepoužíval (například pokud je metoda přiřazena MethodImplOptions.AggressiveOptimization), se použije plně optimalizace JIT.

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

Kód vygenerovaný rychlým jitem může běžet pomaleji, přidělovat více paměti nebo používat více prostoru zásobníku. Pokud dojde k problémům, můžete rychlý JIT zakázat pomocí této vlastnosti MSBuild v souboru projektu:

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

Chcete-li zakázat TC zcela, použijte tuto vlastnost MSBuild v souboru projektu:

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

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

ReadyToRun images

Dobu spuštění aplikace .NET Core můžete vylepšit kompilací sestavení aplikace ve formátu ReadyToRun (R2R). R2R je forma předběžné kompilace (AOT).

Binární soubory R2R zlepšují výkon spouštění snížením množství práce, kterou musí kompilátor JIT (just-in-time) provést při načítání vaší aplikace. Binární soubory obsahují podobný nativní kód ve srovnání s tím, co by jiT vytvořilo. Binární soubory R2R jsou však větší, protože obsahují kód jazyka IL (Intermediate Language), který je stále nutný 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.

Pokud chcete projekt zkompilovat jako ReadyToRun, postupujte takto:

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

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

2. Publikujte samostatnou aplikaci. Tento příkaz například vytvoří samostatnou aplikaci pro 64bitovou verzi Windows:

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

Omezení pro různé platformy nebo architekturu

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

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

• Windows x64 lze použít ke kompilaci imagí Windows Arm32, Arm64 a x86.
• Windows x86 lze použít ke kompilaci imagí Windows Arm32.
• Linux x64 lze použít ke kompilaci imagí Arm32 a Arm64.

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

Modul runtime nebo sada SDK

Přechod za běhu hlavní verze

.NET Core 3.0 zavádí funkci výslovného souhlasu, která vaší aplikaci umožňuje přejít na nejnovější hlavní verzi .NET Core. Kromě toho se přidalo nové nastavení, které určuje, jak se bude v aplikaci používat vrácení vpřed. Můžete ho nakonfigurovat následujícími způsoby:

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

Je třeba zadat jednu z následujících hodnot. Pokud je nastavení vynecháno, podverze je výchozí.

• Nejnovějšípatch
  Přechod na nejvyšší verzi opravy Tím se zakáže vrácení podverze vpřed.
• Moll
  Pokud chybí požadovaná podverze, přejděte na nejnižší nižší podverzi. Pokud je požadovaná podverze k dispozici, použije se zásada LatestPatch .
• Major
  Pokud chybí požadovaná hlavní verze, přejděte na nejnižší vyšší hlavní verzi a nejnižší podverzi. Pokud je požadovaná hlavní verze přítomen, použije se podverze .
• LatestMinor
  Převést na nejvyšší podverzi, i když je požadovaná podverze k dispozici. Určeno pro scénáře hostování komponent.
• LatestMajor
  Převést na nejvyšší hlavní a nejvyšší podverzi, i když je požadovaná hlavní verze přítomna. Určeno pro scénáře hostování komponent.
• Zakázat
  Nevrácej se dopředu. Vytvořit vazbu pouze na zadanou verzi. Tato zásada se nedoporučuje pro obecné použití, protože zakazuje vrátit se 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.

Ve výchozím nastavení platí, že pokud je požadovaná verze (jak je uvedená v .runtimeconfig.json aplikaci) verze, považují se za postupné uvedení 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 DOTNET_ROLL_FORWARD_TO_PRERELEASE=1, v takovém případě jsou všechny verze vždy považovány za.

Sestavení kopíruje závislosti

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

Existují některé operace, jako je oříznutí a publikování stránek razor, které budou i nadá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é k určitému umístění na disku. Místní nástroje nejsou globálně dostupné a distribuují se jako balíčky NuGet.

Místní nástroje spoléhají na název dotnet-tools.json souboru manifestu v aktuálním adresáři. Tento soubor manifestu definuje nástroje, které mají být k dispozici v této složce a níže. Soubor manifestu můžete distribuovat s kódem, abyste zajistili, že každý, kdo pracuje s vaším kódem, může obnovit a používat stejné nástroje.

Pro globální i místní nástroje se vyžaduje kompatibilní verze modulu runtime. Řada nástrojů v současné době NuGet.org cíli na .NET Core Runtime 2.1. Pokud chcete tyto nástroje nainstalovat globálně nebo místně, budete muset nainstalovat modul runtime NET Core 2.1.

Nové možnosti global.json

Soubor global.json obsahuje nové možnosti, které poskytují větší flexibilitu při definování verze sady .NET Core SDK. Nové možnosti jsou:

• allowPrerelease: Určuje, jestli má překladač sady SDK zvážit předběžné verze při výběru verze sady SDK, která se má použít.
• rollForward: Označuje předávací zásadu, která se má použít při výběru verze sady SDK, a to buď jako záložní, pokud chybí konkrétní verze sady SDK, nebo jako direktiva pro použití vyšší verze.

Další informace ozměnách global.json ch

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

Výchozí velikost haldy systému uvolňování paměti se snížila, což vede k tomu, že .NET Core využívá méně paměti. Tato změna lépe odpovídá rozpočtu přidělení generace 0 s moderními velikostmi mezipaměti procesoru.

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

Velké stránky (označované také jako Velké stránky v Linuxu) je funkce, ve které operační systém dokáže vytvořit oblasti paměti větší než nativní velikost 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 je teď možné nakonfigurovat s nastavením GCLargePages jako funkcí pro výslovný souhlas, která se má rozhodnout pro přidělování velkých stránek ve Windows.

Windows Desktop & COM

Instalační služba windows sady .NET Core SDK

Instalační služba MSI pro Windows se změnila od .NET Core 3.0. Instalační programy sady SDK teď upgradují vydané verze sady SDK v pásmu funkcí. Pásma funkcí jsou definována ve stovkách skupin v části opravy čísla verze. Například 3.0.101 a 3.0.Verze 201 jsou ve dvou různých funkčních pásmech, zatímco verze 3.0.101 a 3.0.199 je ve stejném celovečerní kapele. A když .NET Core SDK 3.0.Nainstaluje se 101 , .NET Core SDK 3.0.Pokud existuje, odebere se z počítače 100 . Když .NET Core SDK 3.0.200 se nainstaluje na stejný počítač, .NET Core SDK 3.0.101 se neodebere.

Další informace o správě verzí najdete v tématu Přehled způsobu správy verzí .NET Core.

Plocha Windows

.NET Core 3.0 podporuje desktopové aplikace systému Windows pomocí windows Presentation Foundation (WPF) a model Windows Forms. Tyto architektury také podporují používání moderních ovládacích prvků a stylů Fluent z knihovny XAML uživatelského rozhraní Systému Windows (WinUI) prostřednictvím ostrůvků XAML.

Komponenta Windows Desktop 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 portování existující aplikace rozhraní .NET Framework naleznete v tématu Port WPF projekty a port model Windows Forms projekty.

WinForms high DPI

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

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

• DpiUnaware
• SystemAware
• PerMonitor
• PerMonitorV2
• DpiUnawareGdiScaled

Další informace o režimech vysokého DPI naleznete v tématu Vývoj desktopových aplikací s vysokým rozlišením DPI ve Windows.

Vytvoření komponent modelu COM

Ve Windows teď můžete vytvářet spravované komponenty, které se dají volat pomocí modelu COM. Tato funkce je důležitá pro použití .NET Core s modely doplňků modelu COM a také pro zajištění parity s rozhraním .NET Framework.

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

Příklad vytvoření komponenty MODELU COM a jeho využití najdete v ukázce modelu COM.

Nativní interoperabilita windows

Windows nabízí bohaté nativní rozhraní API ve formě plochých rozhraní API C, com a WinRT. I když .NET Core podporuje volání P/Invoke, .NET Core 3.0 přidává možnost coCreate COM API a aktivovat rozhraní WinRT API. Příklad kódu najdete v ukázce Excelu.

Nasazení MSIX

MSIX je nový formát balíčku aplikací pro Windows. Dá se použít k nasazení desktopových aplikací .NET Core 3.0 do Windows 10.

Projekt Windows Application Packaging, který je k dispozici v sadě Visual Studio 2019, umožňuje vytvářet balíčky MSIX pomocí samostatných aplikací .NET Core.

Soubor projektu .NET Core musí v této vlastnosti zadat podporované moduly <RuntimeIdentifiers> runtime:

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

Vylepšení Linuxu

SerialPort pro Linux

.NET Core 3.0 poskytuje základní podporu pro System.IO.Ports.SerialPort Linux.

Dříve se .NET Core podporovalo jenom ve SerialPort Windows.

Další informace o omezené podpoře sériového portu v Linuxu najdete v tématu Problém GitHubu č. 33146.

Omezení paměti Dockeru a cgroup

Spuštění .NET Core 3.0 v Linuxu s Dockerem funguje lépe s limity paměti cgroup. Spuštění kontejneru Dockeru s omezeními paměti, například s docker run -m, změní způsob chování .NET Core.

• Výchozí velikost haldy uvolňování paměti (GC): maximálně 20 mb nebo 75 % limitu paměti v kontejneru.
• Explicitní velikost lze nastavit jako absolutní číslo nebo procento limitu skupiny cgroup.
• Minimální velikost rezervovaného segmentu na haldu GC je 16 mb. Tato velikost zmenšuje počet hald, které se vytvářejí na počítačích.

Podpora GPIO pro Raspberry Pi

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

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

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

Podpora Arm64 Pro Linux

.NET Core 3.0 přidává podporu pro Arm64 pro Linux. Primární případ použití pro Arm64 je v současné době ve scénářích IoT. Další informace najdete v tématu Stav Arm64 pro .NET Core.

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

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, když je dostupná v daném prostředí. S protokolem TLS 1.3:

• Časy připojení se vylepšují a vyžadují se kratší doby odezvy mezi klientem a serverem.
• Vylepšené zabezpečení z důvodu odebrání různých zastaralých a nezabezpečených kryptografických algoritmů

Pokud 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 OpenSSL 1.1.1 , oba System.Net.Security.SslStream typy System.Net.Http.HttpClient budou používat protokol TLS 1.3 (za předpokladu, že klient i server podporují protokol TLS 1.3).

Následující příklad C# 8.0 ukazuje .NET Core 3.0 na Ubuntu 18.10 připojení 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é s System.Security.Cryptography.AesGcm a System.Security.Cryptography.AesCcm v uvedeném pořadí. Oba tyto algoritmy jsou ověřené šifrování s algoritmy AEAD (Association Data).

Následující kód ukazuje 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 a 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

• Soukromý klíč

  • PKCS#8 PrivateKeyInfo
  • PKCS#8 EncryptedPrivateKeyInfo

Klíče RSA také podporují:

• Veřejný klíč

  • PKCS#1 RSAPublicKey

• Soukromý klíč

  • PKCS#1 RSAPrivateKey

Metody exportu vytvářejí binární data s kódováním DER a metody importu očekávají stejné. 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í 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 lze zkontrolovat pomocí System.Security.Cryptography.Pkcs.Pkcs8PrivateKeyInfo souborů System.Security.Cryptography.Pkcs.Pkcs12InfoPFX/PKCS#12. Soubory PFX/PKCS#12 lze manipulovat s System.Security.Cryptography.Pkcs.Pkcs12Builder.

Změny rozhraní API .NET Core 3.0

Rozsahy a indexy

Nový System.Index typ lze použít k indexování. Můžete ho vytvořit z int počátku nebo pomocí operátoru předpony ^ (C#), který se počítá z 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"

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

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

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

Asynchronní streamy

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

Následující příklad ukazuje produkční i spotřebu asynchronních datových proudů. Příkaz foreach je asynchronní a sám používá yield return k vytvoření asynchronního datového proudu pro volající. Tento model (pomocí yield return) je doporučeným modelem 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 await foreachje možné , můžete také vytvořit asynchronní iterátory, například iterátor, který vrátí IAsyncEnumerable/IAsyncEnumerator to, co můžete a await yield v. Pro objekty, které je třeba odstranit, můžete použít IAsyncDisposable, které různé typy seznamu BCL implementují, například Stream a Timer.

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

Plovoucí desetiná čárka IEEE

Rozhraní API s plovoucí desetinou čárkou se aktualizují tak, aby vyhovovala revizi IEEE 754-2008. Cílem těchto změn je zveřejnit všechny požadované operace a zajistit, aby byly v souladu se specifikací IEEE. Další informace o vylepšení s plovoucí desetinou čárkou najdete v blogovém příspěvku .NET Core 3.0 s vylepšením parsování a formátování s plovoucí desetinou čárkou.

Mezi opravy analýzy a formátování patří:

• Správně parsovat a zaokrouhlovat vstupy libovolné délky.
• Správně parsovat a formátovat zápornou nulu.
• Správně parsujte Infinity a NaN provedete kontrolu bez rozlišování malých a malých písmen a povolíte volitelnou předchozí možnost + , pokud je to možné.

Mezi nová System.Math rozhraní API patří:

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

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

• ILogB(Double)
  logB Odpovídá operaci IEEE, která vrací celočíselnou hodnotu, vrátí celočíselný protokol base-2 vstupního parametru. Tato metoda je v podstatě stejná jako floor(log2(x)), ale provádí s minimální chybou zaokrouhlování.

• ScaleB(Double, Int32)
  scaleB Odpovídá operaci IEEE, která přebírá celočíselnou hodnotu, vrací efektivně x * pow(2, n), ale provádí se s minimální chybou zaokrouhlování.

• Log2(Double)
  log2 Odpovídá operaci IEEE, vrací logaritmus base-2. Minimalizuje chybu zaokrouhlování.

• FusedMultiplyAdd(Double, Double, Double)
  fma Odpovídá operaci IEEE, provádí sloučené sčítání násobení. To znamená, že se jedná (x * y) + z o jednu operaci, čímž minimalizuje chybu zaokrouhlení. Příkladem je FusedMultiplyAdd(1e308, 2.0, -1e308), který vrátí 1e308. Běžná (1e308 * 2.0) - 1e308 návratová hodnota double.PositiveInfinity.

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

Vnitřní objekty závislé na platformě .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 sady instrukcí SIMD nebo Bit Manipulat. Tyto pokyny můžou pomoct dosáhnout významných vylepšení výkonu v určitých scénářích, jako je efektivní paralelní zpracování dat.

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

Další informace najdete v tématu Vnitřní funkce závislé na platformě .NET.

Vylepšená rozhraní API pro verze .NET Core

Počínaje .NET Core 3.0 teď rozhraní API verze poskytovaná v .NET Core vrací očekávané informace. Pří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

Rychlá integrovaná podpora JSON

Uživatelé .NET se do značné míry spoléhali na Newtonsoft.Json a další oblíbené knihovny JSON, které jsou i nadále dobrou volbou. Newtonsoft.Json používá řetězce .NET jako základní datový typ, což je UTF-16 pod kapotou.

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

• Serializace JSON v .NET – přehled
• Jak serializovat a deserializovat JSON v .NET
• Jak migrovat z Newtonsoft.Json na System.Text.Json

Podpora HTTP/2

Typ System.Net.Http.HttpClient podporuje protokol HTTP/2. Pokud je povolený protokol HTTP/2, verze protokolu HTTP se vyjedná prostřednictvím protokolu 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 HTTP/2 je možné povolit dvěma různými způsoby. Nejprve můžete nastavit zprávu požadavku HTTP tak, aby používala 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é můžete ve výchozím nastavení změnit HttpClient použití protokolu 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);

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

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

Další kroky

• Projděte si zásadní změny mezi .NET Core 2.2 a 3.0.
• Projděte si zásadní změny v .NET Core 3.0 pro model Windows Forms aplikace.