A .NET Core 3.0 újdonságai

Ez a cikk a .NET Core 3.0 újdonságát ismerteti. Az egyik legnagyobb fejlesztés a Windows asztali alkalmazások támogatása (csak Windows esetén). A Windows Desktop .NET Core 3.0 SDK-összetevőjével portozhatja a Windows Forms és Windows megjelenítési alaprendszer (WPF) alkalmazásokat. Az egyértelműség érdekében a Windows Desktop összetevő csak a Windowsban támogatott és elérhető. További információkért tekintse meg a cikk későbbi, Asztali Windows szakaszát.

A .NET Core 3.0 támogatja a C# 8.0-t. Javasoljuk, hogy a Visual Studio 2019 16.3-s vagy újabb verzióját, vagy a Legújabb C#-bővítményt tartalmazó Visual Studio Code-ot használja.

Töltse le és kezdje el a .NET Core 3.0-s verziójának használatát Windows, macOS vagy Linux rendszeren.

A kiadással kapcsolatos további információkért lásd a .NET Core 3.0 bejelentését.

A .NET Core 3.0 RC 1-et a Microsoft éles üzemkésznek tekintette, és teljes mértékben támogatja. Ha előzetes verziójú kiadást használ, a folyamatos támogatás érdekében át kell lépnie az RTM-verzióra.

Nyelvi fejlesztések C# 8.0

A C# 8.0 is része ennek a kiadásnak, amely magában foglalja a null értékű referenciatípusok funkciót, az aszinkron streameket és további mintákat. A C# 8.0 funkcióiról további információt a C# 8.0 újdonságai című témakörben talál.

A C# 8.0 nyelvi funkcióival kapcsolatos oktatóanyagok:

• Oktatóanyag: A tervezési szándék egyértelműbb kifejezése null értékű és nem null értékű hivatkozástípusokkal
• Oktatóanyag: Aszinkron streamek létrehozása és felhasználása a C# 8.0 és a .NET Core 3.0 használatával
• Oktatóanyag: Mintamegfeleltetés használata típusalapú és adatvezérelt algoritmusok létrehozásához

Nyelvi fejlesztések lettek hozzáadva az alábbi API-funkciók támogatásához:

• Tartományok és indexek
• Aszinkron streamek

.NET Standard 2.1

A .NET Core 3.0 a .NET Standard 2.1-et implementálja. Az alapértelmezett dotnet new classlib sablon azonban létrehoz egy projektet, amely továbbra is a .NET Standard 2.0-t célozza. A .NET Standard 2.1 célzásához szerkessze a projektfájlt, és módosítsa a tulajdonságot a TargetFramework következőrenetstandard2.1:

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

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

</Project>

Ha Visual Studiót használ, akkor a Visual Studio 2019-re van szüksége, mivel a Visual Studio 2017 nem támogatja a .NET Standard 2.1-et vagy a .NET Core 3.0-t.

Fordítás/üzembe helyezés

Alapértelmezett végrehajtható fájlok

A .NET Core mostantól alapértelmezés szerint keretrendszerfüggő végrehajtható fájlokat készít. Ez a viselkedés a .NET Core globálisan telepített verzióját használó alkalmazások esetében új. Korábban csak a saját üzemeltetésű példányok hoztak létre végrehajtható példányokat .

Közben dotnet build vagy dotnet publishalatt egy végrehajtható (más néven appHost) jön létre, amely megfelel a használt SDK környezetének és platformjának. Ugyanezekre számíthat ezekkel a végrehajtható fájlokkal, mint a többi natív végrehajtható fájl, például:

• Kattintson duplán a végrehajtható fájlra.
• Az alkalmazást közvetlenül egy parancssorból indíthatja el, például myapp.exe Windowson, Linuxon ./myapp és macOS rendszeren.

macOS appHost és notarization

csak macOS

A macOS-hez készült notarized .NET Core SDK 3.0-tól kezdve alapértelmezés szerint le van tiltva egy alapértelmezett végrehajtható (más néven appHost) beállítás. További információ: macOS Catalina Notarization, valamint a .NET Core-letöltésekre és -projektekre gyakorolt hatás.

Ha az appHost-beállítás engedélyezve van, a .NET Core létrehoz egy natív Mach-O-végrehajtható fájlt a buildelés vagy közzététel során. Az alkalmazás az appHost környezetében fut, amikor a dotnet run parancsot tartalmazó forráskódból futtatja, vagy közvetlenül elindítja a Mach-O végrehajtható fájlt.

Az appHost nélkül a felhasználó csak a paranccsal indíthat keretrendszerfüggő alkalmazástdotnet <filename.dll>. Az appHost mindig létrejön, amikor önkiszolgálóan teszi közzé az alkalmazást.

Konfigurálhatja az appHostot a projekt szintjén, vagy az appHost kapcsolót egy adott dotnet parancshoz a -p:UseAppHost paraméterrel:

• Projektfájl

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

• Parancssori paraméter

  dotnet run -p:UseAppHost=true
  

A beállításról további információt a UseAppHost Microsoft.NET.Sdk MSBuild tulajdonságai című témakörben talál.

Egyfájlos végrehajtható fájlok

A dotnet publish parancs támogatja az alkalmazás platformspecifikus egyfájlos végrehajthatóvá való csomagolását. A végrehajtható fájl önkitermelő, és tartalmazza az alkalmazás futtatásához szükséges összes függőséget (beleértve a natívt is). Az alkalmazás első futtatásakor az alkalmazás ki lesz nyerve egy könyvtárba az alkalmazás neve és buildazonosítója alapján. Az indítás gyorsabb az alkalmazás újrafuttatásakor. Az alkalmazásnak nem kell másodszor kinyernie magát, hacsak nem használ új verziót.

Egy fájlból álló végrehajtható fájl közzétételéhez állítsa be a PublishSingleFile projektet vagy a parancssort a dotnet publish következő paranccsal:

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

-vagy-

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

Az egyfájlos közzétételről további információt az egyfájlos csomagköteg-terveződokumentumban talál.

Szerelvény vágása

A .NET Core 3.0 SDK olyan eszközzel rendelkezik, amely az IL elemzésével és a nem használt szerelvények vágásával csökkentheti az alkalmazások méretét.

Az önálló alkalmazások tartalmazzák a kód futtatásához szükséges összes elemet anélkül, hogy a .NET-et a gazdaszámítógépre kellene telepíteni. Az alkalmazás azonban sokszor csak a keretrendszer egy kis részhalmazát igényli a működéshez, és más nem használt kódtárak is eltávolíthatók.

A .NET Core mostantól tartalmaz egy beállítást, amely az IL Trimmer eszközzel ellenőrzi az alkalmazás IL-ját. Ez az eszköz észleli a szükséges kódot, majd levágja a nem használt kódtárakat. Ez az eszköz jelentősen csökkentheti egyes alkalmazások üzembehelyezési méretét.

Az eszköz engedélyezéséhez adja hozzá a beállítást a <PublishTrimmed> projekthez, és tegyen közzé egy önálló alkalmazást:

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

dotnet publish -r <rid> -c Release

Példaként az alapszintű "hello world" új konzolprojektsablon, amely közzétételkor körülbelül 70 MB méretű. A használatával <PublishTrimmed>ez a méret körülbelül 30 MB-ra csökken.

Fontos figyelembe venni, hogy a tükrözést vagy a kapcsolódó dinamikus funkciókat használó alkalmazások vagy keretrendszerek (beleértve a ASP.NET Core-t és a WPF-et is) gyakran megszakadnak a vágáskor. Ez a törés azért fordul elő, mert a vágó nem tud erről a dinamikus viselkedésről, és nem tudja meghatározni, hogy mely keretrendszertípusok szükségesek a tükrözéshez. Az IL Trimmer eszköz konfigurálható úgy, hogy tisztában legyen ezzel a forgatókönyvel.

Mindenek előtt mindenképpen tesztelje az alkalmazást a vágás után.

Az IL Trimmer eszközzel kapcsolatos további információkért tekintse meg a dokumentációt, vagy látogasson el a mono/linker adattárba.

Rétegzett fordítás

A rétegzett fordítás (TC) alapértelmezés szerint be van kapcsolva a .NET Core 3.0-val. Ez a funkció lehetővé teszi, hogy a futtatókörnyezet adaptívabban használja a just-in-time (JIT) fordítót a jobb teljesítmény érdekében.

A rétegzett fordítás fő előnye, hogy kétféleképpen lehet jitting metódusokat használni: alacsonyabb minőségű, de gyorsabb vagy magasabb minőségű, de lassabb rétegben. A minőség azt jelenti, hogy a módszer mennyire van optimalizálva. A TC segít az alkalmazások teljesítményének javításában a végrehajtás különböző szakaszaiban, az indítástól az állandó állapoton át. Ha a rétegzett fordítás le van tiltva, a rendszer minden metódust egyetlen módon állít össze, amely torzítja az indítási teljesítmény állandó állapotú teljesítményét.

Ha a TC engedélyezve van, az alábbi viselkedés vonatkozik a metódusok fordítására egy alkalmazás indításakor:

• Ha a metódus előre lefordított kóddal vagy ReadyToRun-sel rendelkezik, a rendszer az előre összeállított kódot használja.
• Ellenkező esetben a metódus jitted. Ezek a metódusok általában általánosak az értéktípusoknál.
  • A Quick JIT gyorsabban készít alacsonyabb minőségű (vagy kevésbé optimalizált) kódot. A .NET Core 3.0-ban a gyors JIT alapértelmezés szerint engedélyezve van olyan metódusok esetében, amelyek nem tartalmaznak hurkokat, és az indításkor előnyben részesítik.
  • A teljes mértékben optimalizált JIT lassabban állítja elő a jobb minőségű (vagy optimalizáltabb) kódot. Az olyan metódusok esetében, ahol a Quick JIT nem lenne használatban (például ha a metódust a rendszer hozzárendeli MethodImplOptions.AggressiveOptimization), a rendszer a teljes mértékben optimalizált JIT-t használja.

A gyakran használt metódusok esetében a just-in-time fordító végül teljesen optimalizált kódot hoz létre a háttérben. Az optimalizált kód ezután lecseréli a metódus előre lefordított kódját.

A Quick JIT által létrehozott kód lassabban fut, több memóriát foglal le, vagy több veremterületet használ. Ha problémák merülnek fel, letilthatja a Quick JIT szolgáltatást a projektfájlban található MSBuild tulajdonsággal:

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

A TC teljes letiltásához használja ezt az MSBuild tulajdonságot a projektfájlban:

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

Tipp.

Ha módosítja ezeket a beállításokat a projektfájlban, előfordulhat, hogy tiszta buildet kell végrehajtania ahhoz, hogy az új beállítások megjelenjenek (törölje a könyvtárakat és bin az obj újraépítést).

A fordítás futásidőben történő konfigurálásáról további információt a fordítás futásidejű konfigurációs beállításai között talál.

ReadyToRun-képek

Az alkalmazásszerelvények ReadyToRun (R2R) formátumként való összeállításával javíthatja a .NET Core-alkalmazás indítási idejét. Az R2R az idő előtti fordítás (AOT) egyik formája.

Az R2R bináris fájljai úgy javítják az indítási teljesítményt, hogy csökkentik az igény szerinti (JIT) fordítónak az alkalmazás betöltésekor szükséges munkáját. A bináris fájlok hasonló natív kódot tartalmaznak, mint a JIT által előállított kód. Az R2R bináris fájlok azonban nagyobbak, mert mind a köztes nyelvi (IL) kódot tartalmazzák, amelyre bizonyos forgatókönyvek esetében még szükség van, és ugyanannak a kódnak a natív verzióját is tartalmazzák. Az R2R csak akkor érhető el, ha olyan önálló alkalmazást tesz közzé, amely meghatározott futtatókörnyezeteket (RID- például Linux x64 vagy Windows x64) céloz meg.

A projekt ReadyToRunként való fordításához tegye a következőket:

1. Adja hozzá a <PublishReadyToRun> beállítást a projekthez:

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

2. Önálló alkalmazás közzététele. Ez a parancs például létrehoz egy önálló alkalmazást a Windows 64 bites verziójához:

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

Platformfüggetlen/architektúra-korlátozások

A ReadyToRun fordító jelenleg nem támogatja a keresztcélzást. Egy adott célon kell lefordítania. Ha például R2R-lemezképeket szeretne használni a Windows x64-hez, akkor a közzétételi parancsot kell futtatnia ezen a környezetben.

A keresztcélzás alóli kivételek:

• A Windows x64 a Windows Arm32, Arm64 és x86 rendszerképek fordítására használható.
• A Windows x86 használható Windows Arm32-rendszerképek fordítására.
• Linux x64 használható Linux Arm32- és Arm64-rendszerképek fordítására.

További információ: Futtatásra kész.

Futtatókörnyezet/SDK

Főverziós futtatókörnyezet előregörgetése

A .NET Core 3.0 egy olyan bejelentkezési funkciót vezet be, amely lehetővé teszi az alkalmazás számára, hogy a .NET Core legújabb főverziójára lépjen. Emellett egy új beállítás is hozzáadva annak szabályozásához, hogy a rendszer hogyan alkalmazza a bevezetést az alkalmazásra. Ez a következő módokon konfigurálható:

• Projektfájl tulajdonsága: RollForward
• Futtatókörnyezet konfigurációs fájltulajdonság: rollForward
• Környezeti változó: DOTNET_ROLL_FORWARD
• Parancssori argumentum: --roll-forward

Az alábbi értékek egyikét kell megadni. Ha a beállítás nincs megadva, az alverzió az alapértelmezett.

• LatestPatch
  Ugrás a legmagasabb javításverzióra. Ez letiltja az alverzió továbbgördítését.
• Kiskorú
  Lépjen tovább a legalacsonyabb alverzióra, ha a kért alverzió hiányzik. Ha a kért alverzió jelen van, akkor a Rendszer a LatestPatch szabályzatot használja.
• Őrnagy
  Ha a főverzió hiányzik, lépjen tovább a legalacsonyabb főverzióra és a legalacsonyabb alverzióra. Ha a kért főverzió jelen van, akkor a rendszer az Alszabályzatot használja.
• LatestMinor
  Lépjen tovább a legmagasabb alverzióra, még akkor is, ha a kért alverzió jelen van. Komponens-üzemeltetési forgatókönyvekhez készült.
• LatestMajor
  Ugrás a legmagasabb főverzióra és a legmagasabb alverzióra, még akkor is, ha a kért főverzió jelen van. Komponens-üzemeltetési forgatókönyvekhez készült.
• Letiltás
  Ne lépkedjetek előre. Csak a megadott verzióhoz kötés. Ez a szabályzat nem ajánlott általános használatra, mert letiltja a legújabb javításokra való ugrás lehetőségét. Ez az érték csak teszteléshez ajánlott.

A Letiltás beállítás mellett minden beállítás a legmagasabb elérhető javításverziót fogja használni.

Alapértelmezés szerint ha a kért verzió (az alkalmazáshoz megadott .runtimeconfig.json ) kiadási verzió, akkor a rendszer csak a kiadási verziókat veszi figyelembe a bevezetéshez. A rendszer figyelmen kívül hagyja a kiadás előtti verziókat. Ha nincs egyező kiadási verzió, akkor a kiadás előtti verziók is figyelembe lesznek véve. Ez a viselkedés a beállítással DOTNET_ROLL_FORWARD_TO_PRERELEASE=1módosítható, ebben az esetben minden verziót figyelembe kell venni.

Másolási függőségek létrehozása

A dotnet build parancs most átmásolja az alkalmazás NuGet-függőségeit a NuGet-gyorsítótárból a build kimeneti mappájába. Korábban a függőségek csak a program részeként dotnet publishlettek másolva.

Vannak olyan műveletek, például a vágás és a borotvaoldal-közzététel, amelyek továbbra is közzétételt igényelnek.

Helyi eszközök

A .NET Core 3.0 helyi eszközöket vezet be. A helyi eszközök hasonlóak a globális eszközökhöz, de a lemez egy adott helyéhez vannak társítva. A helyi eszközök globálisan nem érhetők el, és NuGet-csomagként vannak elosztva.

A helyi eszközök az aktuális könyvtárban lévő jegyzékfájl nevére dotnet-tools.json támaszkodnak. Ez a jegyzékfájl határozza meg azokat az eszközöket, amelyeket az adott mappában és az alatt elérhetővé kell tenni. A jegyzékfájlt eloszthatja a kóddal, hogy mindenki, aki a kóddal dolgozik, visszaállíthassa és használhatja ugyanazokat az eszközöket.

A globális és a helyi eszközökhöz a futtatókörnyezet kompatibilis verziójára is szükség van. Számos eszköz jelenleg NuGet.org .NET Core Runtime 2.1-et céloz meg. Ha ezeket az eszközöket globálisan vagy helyileg szeretné telepíteni, akkor is telepítenie kell a NET Core 2.1 futtatókörnyezetet.

Új global.json lehetőségek

A global.json fájl új lehetőségekkel rendelkezik, amelyek nagyobb rugalmasságot biztosítanak a .NET Core SDK melyik verziójának meghatározásakor. Az új lehetőségek a következők:

• allowPrerelease: Azt jelzi, hogy az SDK-feloldónak fontolóra kell-e vennie az előzetes verziókat a használni kívánt SDK-verzió kiválasztásakor.
• rollForward: Az SDK-verzió kiválasztásakor használandó roll-forward szabályzatot jelzi, akár tartalékként, ha egy adott SDK-verzió hiányzik, vagy irányelvként egy magasabb verziót használ.

Az alapértelmezett értékekkel, a támogatott értékekkel és az új egyező szabályokkal kapcsolatos további információkért tekintse meg global.json áttekintését.

Kisebb szemétgyűjtési halomméretek

A Szemétgyűjtő alapértelmezett halommérete csökkent, így a .NET Core kevesebb memóriát használ. Ez a változás jobban igazodik a 0. generációs foglalási költségvetéshez a modern processzorgyorsítótár-méretekhez.

Szemétgyűjtés – nagy lap támogatása

A Nagyméretű lapok (más néven Hatalmas lapok Linuxon) egy olyan funkció, amelyben az operációs rendszer képes a natív oldalméretnél (gyakran 4K) nagyobb memóriarégiók létrehozására a nagy oldalakat kérő alkalmazás teljesítményének javítása érdekében.

A Szemétgyűjtő mostantól konfigurálható a GCLargePages beállítással, mint egy bejelentkezési funkció, amellyel nagy oldalakat foglalhat le a Windowson.

Windows Desktop > COM

.NET Core SDK Windows Installer

A Windows MSI-telepítője a .NET Core 3.0-tól kezdve megváltozott. Az SDK telepítői mostantól frissítik az SDK funkciósávos kiadásait. A funkciósávok a verziószám javítás szakaszának több száz csoportjában vannak definiálva. Például: 3.0.101 és 3.0.A 201 két különböző funkciósávban, míg a 3.0-s verzióban érhető el.101 és 3.0.199 ugyanabban a játéksávban van. És amikor a .NET Core SDK 3.0.A 101 telepítve van, a .NET Core SDK 3.0.100 törlődik a gépről, ha létezik. Amikor .NET Core SDK 3.0.A 200 ugyanazon a gépen van telepítve, a .NET Core SDK 3.0.A 101 nem lesz eltávolítva.

A verziószámozással kapcsolatos további információkért tekintse meg a .NET Core verziószámozásának áttekintését.

Asztali Windows

A .NET Core 3.0 támogatja a Windows asztali alkalmazásokat Windows megjelenítési alaprendszer (WPF) és Windows Forms használatával. Ezek a keretrendszerek a Windows UI XAML-kódtár (WinUI) XAML-szigeteken keresztüli modern vezérlőinek és Fluent-stílusának használatát is támogatják.

A Windows Desktop összetevő a Windows .NET Core 3.0 SDK része.

Létrehozhat egy új WPF- vagy Windows Forms-alkalmazást a következő dotnet parancsokkal:

dotnet new wpf
dotnet new winforms

A Visual Studio 2019 új projektsablonokat ad hozzá a .NET Core 3.0 Windows Formshoz és WPF-hez.

A meglévő .NET-keretrendszer-alkalmazások portolásával kapcsolatos további információkért lásd a Port WPF-projekteket és a Port Windows Forms-projekteket.

WinForms magas DPI

A .NET Core Windows Forms-alkalmazások magas DPI-módot állíthatnak be.Application.SetHighDpiMode(HighDpiMode) A SetHighDpiMode metódus beállítja a megfelelő magas DPI-módot, kivéve, ha a beállítást más módon állította be, például App.Manifest p/invoke korábban Application.Run.

Az enumerálás által kifejezett lehetséges highDpiMode értékek a System.Windows.Forms.HighDpiMode következők:

• DpiUnaware
• SystemAware
• PerMonitor
• PerMonitorV2
• DpiUnawareGdiScaled

A magas DPI-módokkal kapcsolatos további információkért lásd : High DPI Desktop Application Development on Windows.

COM-összetevők létrehozása

Windows rendszeren mostantól com-callable felügyelt összetevőket hozhat létre. Ez a képesség kritikus fontosságú a .NET Core com-bővítménymodellekkel való használatához, valamint a .NET-keretrendszer paritásának biztosításához.

Ellentétben .NET-keretrendszer, ahol a mscoree.dll com-kiszolgálóként használták, a .NET Core a COM-összetevő létrehozásakor natív indító dll-et ad hozzá a tárolókönyvtárhoz.

A COM-összetevők létrehozásának és felhasználásának módját a COM-bemutatóban tekintheti meg.

Windows natív interop

A Windows gazdag natív API-t kínál lapos C API-k, COM és WinRT formájában. Míg a .NET Core támogatja a P/Invoke protokollt, a .NET Core 3.0 lehetővé teszi a COM API-k létrehozását és a WinRT API-k aktiválását. Példakódért tekintse meg az Excel bemutatóját.

MSIX-telepítés

Az MSIX egy új Windows-alkalmazáscsomag-formátum. A .NET Core 3.0 asztali alkalmazások Windows 10-ben való üzembe helyezésére használható.

A Visual Studio 2019-ben elérhető Windows Application Packaging Project lehetővé teszi MSIX-csomagok létrehozását önálló .NET Core-alkalmazásokkal .

A .NET Core-projektfájlnak meg kell adnia a támogatott futtatókörnyezeteket a <RuntimeIdentifiers> tulajdonságban:

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

Linux-fejlesztések

SerialPort for Linux

A .NET Core 3.0 alapvető támogatást nyújt Linux System.IO.Ports.SerialPort rendszeren.

Korábban a .NET Core csak Windows rendszeren támogatott SerialPort .

A linuxos soros port korlátozott támogatásáról további információt a GitHub 33146-os számú problémájában talál.

A Docker és a cgroup memóriakorlátjai

A .NET Core 3.0 linuxos futtatása a Dockerrel jobban működik a cgroup memóriakorlátjaival. A memóriakorlátokkal rendelkező Docker-tárolók futtatása, például a docker run -m.NET Core viselkedésének módosítása.

• Alapértelmezett szemétgyűjtő (GC) halomméret: a tároló memóriakorlátjának legfeljebb 20 mb vagy 75%-a.
• Az explicit méret megadható abszolút számként vagy a csoport korlátjának százalékos arányaként.
• A fenntartott szegmensek minimális mérete GC-halomonként 16 mb. Ez a méret csökkenti a gépeken létrehozott halom halom számát.

GPIO-támogatás Raspberry Pi-hez

Két csomag jelent meg a NuGetben, amelyeket a GPIO-programozáshoz használhat:

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

A GPIO-csomagok a GPIO, SPI, I2C és PWM-eszközök API-jait tartalmazzák. Az IoT-kötések csomagja eszközkötéseket tartalmaz. További információkért tekintse meg a GitHub-adattárat.

Arm64 Linux-támogatás

A .NET Core 3.0 támogatja a Linuxhoz készült Arm64-et. Az Arm64 elsődleges használati esete jelenleg IoT-forgatókönyvekben van. További információ: .NET Core Arm64 Status.

Az Arm64-en futó .NET Core-hoz készült Docker-képek az Alpine, a Debian és az Ubuntu számára érhetők el.

Feljegyzés

A macOS Arm64 (vagy "Apple Silicon") és a Windows Arm64 operációs rendszerek támogatása később a .NET 6-ban lett hozzáadva.

Biztonság

TLS 1.3 & OpenSSL 1.1.1 Linux rendszeren

A .NET Core most már kihasználja az OpenSSL 1.1.1 TLS 1.3 támogatását, ha egy adott környezetben érhető el. TLS 1.3 esetén:

• A kapcsolati idők javulnak az ügyfél és a kiszolgáló között szükséges rövidebb oda-visszaúttal.
• Nagyobb biztonság a különböző elavult és nem biztonságos titkosítási algoritmusok eltávolítása miatt.

Ha elérhető, a .NET Core 3.0 OpenSSL 1.1.1, OpenSSL 1.1.0 vagy OpenSSL 1.0.2 rendszert használ Linux rendszeren. Ha az OpenSSL 1.1.1 elérhető, mindkét System.Net.Security.SslStream típus System.Net.Http.HttpClient a TLS 1.3-at fogja használni (feltételezve, hogy az ügyfél és a kiszolgáló is támogatja a TLS 1.3-at).

Az alábbi C# 8.0-példa a .NET Core 3.0-t mutatja be az Ubuntu 18.10-hez https://www.cloudflare.comvaló csatlakozáskor:

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

Titkosítási titkosítási titkosítások

A .NET Core 3.0 támogatja az AES-GCM és az AES-CCM titkosításokat, amelyek implementálva System.Security.Cryptography.AesGcm System.Security.Cryptography.AesCcm és végrehajtva. Ezek az algoritmusok a társítás adataival (AEAD) rendelkező hitelesített titkosítási algoritmusok.

Az alábbi kód bemutatja, hogy titkosítja AesGcm és visszafejti a véletlenszerű adatokat a titkosításhoz és a visszafejtéshez.

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

Titkosítási kulcs importálása/exportálása

A .NET Core 3.0 támogatja az aszimmetrikus nyilvános és titkos kulcsok importálását és exportálását standard formátumokból. Nem kell X.509-tanúsítványt használnia.

Minden kulcstípus, például RSA, DSA, ECDsa és ECDiffieHellman, támogatja a következő formátumokat:

• Nyilvános kulcs

  • X.509 SubjectPublicKeyInfo

• Titkos kulcs

  • PKCS#8 PrivateKeyInfo
  • PKCS#8 EncryptedPrivateKeyInfo

Az RSA-kulcsok a következőket is támogatják:

• Nyilvános kulcs

  • PKCS#1 RSAPublicKey

• Titkos kulcs

  • PKCS#1 RSAPrivateKey

Az exportálási módszerek DER-kódolású bináris adatokat hoznak létre, és az importálási módszerek is ugyanezt várják. Ha egy kulcs szövegbarát PEM formátumban van tárolva, a hívónak az importálási metódus meghívása előtt a tartalmat base64-dekódolnia kell.

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

A PKCS#8 fájlokkal System.Security.Cryptography.Pkcs.Pkcs8PrivateKeyInfo vizsgálható, a PFX/PKCS#12 fájlokkal System.Security.Cryptography.Pkcs.Pkcs12Infopedig a . A PFX/PKCS#12 fájlokkal kezelhetők System.Security.Cryptography.Pkcs.Pkcs12Builder.

.NET Core 3.0 API-módosítások

Tartományok és indexek

Az új System.Index típus használható az indexeléshez. Létrehozhat egyet olyanból int , amely az elejétől számít, vagy egy előtag ^ operátorral (C#), amely a végétől számít:

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"

Létezik egy típus is System.Range , amely két Index értékből áll, egy a kezdéshez és egy a végéhez, és egy x..y tartománykifejezéssel (C#) írható. Ezután indexelhet egy Rangeszeletet, amely létrehoz egy szeletet:

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

További információkért tekintse meg a tartományok és indexek oktatóanyagát.

Aszinkron streamek

A IAsyncEnumerable<T> típus a következő új aszinkron verziója IEnumerable<T>. A nyelv lehetővé teszi, await foreach hogy az elemeket felhasználja IAsyncEnumerable<T> , és felhasználja yield return őket elemek előállítására.

Az alábbi példa az aszinkron streamek előállítását és használatát mutatja be. Az foreach utasítás aszinkron, és maga a hívók aszinkron streamjének előállítására használja yield return . Ez a minta (használatával yield return) az aszinkron streamek előállításához ajánlott modell.

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

Amellett, hogy await foreachképes lehet rá, aszinkron iterátorokat is létrehozhat, például egy olyan iterátort, amely egy olyan iterátort IAsyncEnumerable/IAsyncEnumerator ad vissza, amelyet egyszerre await és yield be is adhat. Azokat az objektumokat, amelyeket el kell helyezni, használhatja IAsyncDisposable, amelyeket a különböző BCL-típusok implementálnak, például Stream és Timer.

További információkért tekintse meg az aszinkron streamek oktatóanyagát.

IEEE lebegőpontos

A lebegőpontos API-k frissítése folyamatban van az IEEE 754–2008-ra vonatkozó változatnak megfelelően. Ezeknek a módosításoknak az a célja, hogy minden szükséges műveletet elérhetővé tegyenek, és biztosítsák, hogy azok viselkedési szempontból megfeleljenek az IEEE-specifikációnak. A lebegőpontos fejlesztésekről további információt a .NET Core 3.0 blogbejegyzés lebegőpontos elemzési és formázási fejlesztései című témakörben talál.

Elemzési és formázási javítások:

• Tetszőleges hosszúságú bemenetek helyes elemzése és kerekítése.
• A negatív nulla helyes elemzése és formázása.
• Megfelelően elemezheti Infinity és elvégezheti a kis- és NaN nagybetűk érzéketlen ellenőrzését, és adott esetben engedélyezve van egy opcionális előzmény + .

Az új System.Math API-k a következők:

• BitIncrement(Double) és BitDecrement(Double)
  Megfelel az IEEE- és nextDown az nextUp IEEE-műveleteknek. A legkisebb lebegőpontos számot adja vissza, amely a bemenetnél nagyobb vagy kisebb (vagy kisebb) értéket adja vissza. Például a Math.BitIncrement(0.0) következőt adná vissza double.Epsilon:

• MaxMagnitude(Double, Double) és MinMagnitude(Double, Double)
  Az IEEE- és minNumMag az maxNumMag IEEE-műveleteknek felel meg, a két bemenet (vagy azok) nagyobb vagy kisebb nagyságrendű értékét adja vissza. Például a Math.MaxMagnitude(2.0, -3.0) következőt adná vissza -3.0:

• ILogB(Double)
  logB Az integrál értéket visszaadó IEEE műveletnek felel meg, a bemeneti paraméter 2. alapszintű naplóját adja vissza. Ez a módszer gyakorlatilag megegyezik floor(log2(x))a lekerekítési hibával, de minimális kerekítési hibával történik.

• ScaleB(Double, Int32)
  scaleB Az integrál értéket tartalmazó IEEE-műveletnek felel meg, hatékonyan x * pow(2, n)ad vissza, de minimális kerekítési hibával történik.

• Log2(Double)
  Az IEEE műveletnek log2 felel meg, a 2. alap logaritmust adja vissza. Minimalizálja a kerekítési hibát.

• FusedMultiplyAdd(Double, Double, Double)
  Megfelel az fma IEEE műveletnek, és egy összeolvadt szorzási hozzáadást hajt végre. Ez azt jelenti, hogy egyetlen műveletként működik (x * y) + z , ezáltal minimalizálva a kerekítési hibát. Ilyen például a FusedMultiplyAdd(1e308, 2.0, -1e308)visszaadott 1e308érték. A normál (1e308 * 2.0) - 1e308 eredmény .double.PositiveInfinity

• CopySign(Double, Double)
  Az IEEE műveletnek copySign felel meg, a függvény az érték értékét xadja vissza, de a jelével yegyütt.

.NET platformfüggetlen belső metrikák

Olyan API-k lettek hozzáadva, amelyek lehetővé teszik bizonyos, perf-orientált CPU-utasításokhoz, például a SIMD- vagy bitmanipulációs utasításkészletekhez való hozzáférést. Ezek az utasítások segíthetnek jelentős teljesítménybeli javulást elérni bizonyos forgatókönyvekben, például az adatok hatékony párhuzamos feldolgozásában.

Szükség esetén a .NET-kódtárak elkezdték használni ezeket az utasításokat a teljesítmény javítása érdekében.

További információ: .NET Platformfüggetlen intrinsics.

Továbbfejlesztett .NET Core-verzió API-k

A .NET Core 3.0-tól kezdve a .NET Core-hez biztosított verzió API-k most a várt információkat adják vissza. Példa:

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

Figyelmeztetés

Kompatibilitástörő változás. Ez gyakorlatilag kompatibilitástörő változás, mert a verziószámozási séma megváltozott.

Gyors beépített JSON-támogatás

A .NET-felhasználók nagyrészt a Newtonsoft.Json-ra és más népszerű JSON-kódtárakra támaszkodtak, amelyek továbbra is jó választásnak minősülnek. Newtonsoft.Json A .NET-sztringeket használja alapadattípusként, amely a motorháztető alatt található UTF-16.

Az új beépített JSON-támogatás nagy teljesítményű, alacsony kiosztású, és UTF-8 kódolású JSON-szöveggel működik. A névtérrel és a System.Text.Json típusokkal kapcsolatos további információkért tekintse meg az alábbi cikkeket:

• JSON-szerializálás a .NET-ben – áttekintés
• JSON szerializálása és deszerializálása a .NET-ben.
• Migrálás Newtonsoft.Json-ból System.Text.Json-ba

HTTP/2-támogatás

A System.Net.Http.HttpClient típus támogatja a HTTP/2 protokollt. Ha a HTTP/2 engedélyezve van, a HTTP protokoll verziója a TLS/ALPN-en keresztül, a HTTP/2 pedig akkor lesz használatban, ha a kiszolgáló a használatát választja.

Az alapértelmezett protokoll TOVÁBBRA IS HTTP/1.1, de a HTTP/2 kétféleképpen engedélyezhető. Először beállíthatja, hogy a HTTP-kérés üzenete HTTP/2-t használjon:

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

Másodszor, alapértelmezés szerint a HTTP/2 használatára válthat HttpClient :

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

Amikor egy alkalmazást fejleszt, sokszor titkosítatlan kapcsolatot szeretne használni. Ha tudja, hogy a célvégpont HTTP/2-t fog használni, bekapcsolhatja a titkosítatlan kapcsolatokat a HTTP/2-hez. Bekapcsolhatja a környezeti változó 1 beállításával DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2UNENCRYPTEDSUPPORT vagy az alkalmazáskörnyezetben való engedélyezésével:

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

Következő lépések

• Tekintse át a .NET Core 2.2 és 3.0 közötti kompatibilitástörő változásokat.
• Tekintse át a Windows Forms-alkalmazásokhoz készült .NET Core 3.0 kompatibilitástörő változásait.