Ma bejelentjük, hogy a .NET Core 3.0 utáni következő kiadás a .NET 5 lesz. Ez lesz a következő nagy kiadás a .NET sorozatban.
A jövőben csak egy .NET lesz, amellyel fejleszthetsz többek között Windowst, Linuxot, macOS-t, iOS-t, Androidot, tvOS-t, watchOS-t és WebAssembly-t.
Új .NET API-kat, futási idejű funkciókat és nyelvi funkciókat vezetünk be a .NET 5-ben.
A .NET Core projekttől kezdve mintegy ötvenezer .NET Framework API-t adtunk hozzá a platformhoz. A .NET Core 3.0 pótolja a .NET Framework 4.8 fennmaradt funkcióinak nagy részét, támogatva a Windows Forms-ot, a WPF-et és az Entity Framework 6-ot. A .NET 5 erre a munkára épít, kihasználva a .NET Core és Mono legjobb funkcióit egy platform létrehozásához. Minden modern .NET kódhoz használhatod.
Tervezzük, hogy 2020 novemberében kiadjuk a .NET 5-öt, és az első előzetes megjelenést 2020 első felében indítsuk el. A jövőbeli frissítésekben is támogatni fogja a Visual Studio 2019, a Visual Studio for Mac és a Visual Studio Code frissítésekben.
.NET 5 = .NET Core vNext
A .NET 5 a következő lépés a .NET Core-ban. A projekt célja, hogy javítsa a . NET:
- Építs egy .NET futóidőt és keretrendszert, amely bárhol használható, egységes futási idejű viselkedéssel és fejlesztői tapasztalattal.
- A .NET Core teljes kihasználásával . NET Framework, Xamarin és Mono segítségével bővítik a .NET képességeit.
- A termék egyetlen kódbázisból történő fejlesztésével a fejlesztők (Microsoft és a közösség) együtt dolgozhatnak, és együtt fejleszthetik az összes helyzetet.
Ez az új projekt és irány jelentős fordulópontot jelent a .NET számára. A .NET 5-tel a kódod és a projektfájlok ugyanazok lesznek, bármilyen típusú alkalmazást is építesz. Minden alkalmazás ugyanazokhoz a futásidő-, API- és nyelvi funkciókhoz fér hozzá. Tartalmaz továbbá a CoreFX teljesítményfejlesztéseit is, amelyeket szinte naponta hajtanak végre.
Minden, amit szeretsz a .NET Core-ban, továbbra is létezni fog:
- Nyílt forráskódú és közösségközpontú a GitHubon.
- Platformos megvalósítás.
- Támogatja a platformspecifikus funkciók, mint például Windows űrlapok és WPF Windowson, valamint a Xamarin natív kötései minden natív platformhoz való hivatkozások.
- Magas teljesítmény.
- Szereld egymás mellett.
- Kis projektfájlok (SDK stílusban).
- Kompatibilis parancssori interfészekkel (CLI-k).
- Visual Studio, Visual Studio for Mac és Visual Studio Code integráció.
Vannak még új dolgok is:
- Több lehetőséged lesz a futásidős élményedhez (erről lent bővebben).
- A Java interoperabilitás minden platformon elérhető lesz.
- Több operációs rendszer támogatja az Objective-C és a Swift interoperabilitását.
- A CoreFX kibővül, hogy támogassa az előrejövő (AOT) .NET-et, kisebb területet és több operációs rendszert.
Idén szeptemberben kiadjuk a .NET Core 3.0-t, 2020 novemberében a .NET 5-et, majd tervezzük egy nagyobb verziót is kiadni a . NET:
Kihagytuk a 4-es verziót, mert összezavarná azokat a felhasználókat, akik ismerik a .NET keretrendszert, amely már régóta létezik a 4.x sorozatban. Emellett világosan szeretnénk közvetíteni, hogy a .NET 5 a .NET platform jövője. Ha .NET 5-nek hívjuk, ez a valaha kiadott legmagasabb verzió.
Ezt az alkalmat arra is kihasználjuk, hogy egyszerűsítsük a névadást. Úgy gondoljuk, hogy ha csak egy .NET a legjobb, akkor nincs szükségünk egy tisztázó kifejezésre, mint a "Core". A rövidebb név egyszerűsítés, és azt is közvetíti, hogy a .NET 5 egységes funkcionalitással és viselkedéssel rendelkezik. Természetesen továbbra is használhatod a ".NET Core" nevet, ha szeretnéd.
Futási élmény
A Mono az .NET eredeti cross-platform implementációja. Kezdetben nyílt forráskódú alternatívaként indult a .NET Framework-hez, majd az iPhone/iOS és Android eszközök népszerűségével áttért mobilspecifikusra. A Mono egy futtató, amelyet a Xamarin részeként használnak.
A CoreCLR egy futásidő, amelyet a .NET Core részeként használnak. Elsősorban felhőalkalmazások támogatására használják, beleértve a Microsoft legnagyobb szolgáltatását, és ma már Windows asztali, IoT- és gépi tanulási alkalmazásokban is alkalmazzák.
Összefoglalva, a .NET Core és a Mono runtime-ok sok hasonlóságot mutatnak (hiszen mindkettő .NE runtime), de értékes, egyedi funkciókkal is rendelkeznek. Nagyon logikus, hogy lehetővé tegyük, hogy kiválasszd a kívánt futási élményt. A CoreCLR-t és a Mono-t egymás között cserélhetővé tesszük. Olyan egyszerűvé tesszük, hogy egy kapcsolót építünk, hogy különböző futási beállítások közül válasszunk.
Az alábbi szakaszok bemutatják a .NET 5 fő fókuszát, amelyet tervezünk. Világos képet adnak arról, hogyan tervezzük ezt a két futásidőt külön-külön és együtt.
Nagy áteresztőképesség és magas termelékenység
A .NET kezdetektől fogva a just-in-time fordítókra (JIT-ekre) támaszkodott, hogy a köztes nyelvi (IL) kódot optimalizált gépi kódgá alakítsák. Azóta iparágvezető, JIT alapú menedzselt futtatót építettünk, amely nagyon nagy áteresztőképességgel bír, és javítja a fejlesztői élményt, így a programozás gyorsabb és egyszerű lesz.
A JIT ideális hosszú távú felhő- és kliens helyzetekhez. Képesek kódot generálni, amely bizonyos gépekhez konfigurált, beleértve a CPU utasításait is. A JIT futásidőben képes regenerálni a módszereket is, ami gyorsabbbá teszi a JIT-et, miközben továbbra is lehetősége van rendkívül optimalizált kódverziókat generálni, ha az gyakran használt módszerré válik.
Erőfeszítéseink arra, hogy a ASP.NET Core gyorsabban fusson a Techpower benchmarkon, remek példája a JIT erejének és a CoreCLR-be fektetett befektetésünknek. A .NET Core konténerekhez való megerősítésére irányuló erőfeszítéseink azt is bizonyítják, hogy a futás dinamikusan alkalmazkodik a korlátozott környezetekhez.
A fejlesztői eszközök is remek példák arra, hogy a JIT mennyire igazán jó, mint például a dotnet watch eszközök vagy a szerkesztés és folytatás. Az eszközöknek gyakran többször kell egy folyamatban kompetálniuk és betölteniük a kódot újraindítás nélkül, és ezt nagyon gyorsan kell megtenniük.
A .NET Core vagy .NET Framework fejlesztők elsősorban a JIT-re támaszkodnak. Ezért az élménynek ismerős kell lennie.
A legtöbb .NET 5 működési forgatókönyv alapértelmezett élménye a JIT-alapú CoreCLR futásidőt használja. Két figyelemre méltó kivétel az iOS és a kliens, a Blazor (web assembly), mivel mindkettő előre időzített (AOT) natív fordítást igényel.
Gyors indítás, kis igény és alacsony memóriahasználat
A Mono projekt nagy része mobilra és konzolokra fókuszált. A projekt egyik kulcsfontosságú jellemzője és eredménye a .NET AOT fordító, amely az iparág vezető LLVM fordítóprojektjén alapul. A Mono AOT fordító lehetővé teszi, hogy a .NET kódot egy natív kód futtatható fájlba építsék, amely fut számítógépen, akárcsak a C++ kód. Az AOT által fordított alkalmazások hatékonyan futhatnak kisebb helyeken, és szükség esetén válthatnak átmeneti sebességet az indításhoz.
A Blazor projekt már használja a Mono AOT-t. Ez lesz az egyik első projekt, amely átáll .NET 5-re. Ezt az egyik lehetőségként használjuk fel a terv bizonyítására.
Kétféle AOT megoldás létezik:
- Olyan megoldásra van szükség, amely 100%-ban AOT fordításra van fordítva.
- A legtöbb kód AOT-fordított megoldás, de a JIT vagy értelmezők használhatók olyan kódmintákhoz, amelyek nem AOT-barátok (például általánosok). A mono AOT mindkét esetet támogatja. Az Apple biztonsági okokból iOS-hez és néhány konzolhoz az első AOT-t igényli. A második módszer jobb választás, mert az AOT előnyeit kínálja, és elkerüli néhány hátrányt.
A .NET Native az AOT fordítónk Windows UWP alkalmazásokhoz, és egyben az első fent említett AOT típus példája is. Ebben a konkrét megvalósításban korlátozzuk a .NET API-t és a használható funkciókat. Ebből a tapasztalatból megtanultuk, hogy az AOT megoldásoknak minden olyan aspektust lefedniük kell a .NET API-k és minták tekintetében.
Az AOT fordítás továbbra is szükséges iOS-en, web-összeszerelésen és néhány konzolon. Olyan alkalmazásoknál, amelyek gyorsabb indítást igényelnek vagy alacsony lábnyomot igényelnek, az AOT fordítást opcióvá tesszük.
A projekt születése
Ezt a projektet 2018 decemberében kezdtük el egy bostoni műszaki csapattal. A .NET csapat (Mono/Xamarin és .NET Core) és az Unity tervezési vezetői különféle technikai képességeket és architektúra irányokat mutattak be.
Most csapatként haladunk előre a projektben, egy sor eredményrel. Sok előrelépést értünk el több projektben december óta:
- A minimális réteg definiálja a futásidejű <-> kezelt kódréteget azzal a céllal, hogy elérje a CoreFX nyilvános kódjának >99%-át.
- A MonoVM most már használhatja a CoreFX-et és annak osztálykönyvtárait.
- Futtasd le az összes CoreFX tesztet MonoVM-en a CoreFX implementációval.
- Futtatd ASP.NET Core 3.0 alkalmazásokat MonoVM-vel.
- Futtasd a MonoDevelop-t CoreCLR-en, majd futtasd a Visual Studio-t Mac-re.
Migráció egyetlen . A .NET megvalósítása fontos kérdéseket vet fel: Mi lesz a célkeret? Ugyanazok a NuGet csomagkompatibilitási szabályok? Milyen munkaterheléseket kellene támogatnia a .NET 5 SDK-nak? Hogyan kódoljak egy adott architektúrához? Szükségünk van még .NET Standardra? Most dolgozunk ezeken a problémákon, és hamarosan megosztjuk a tervezési dokumentumot, hogy elolvashassák és visszajelzést adjanak.
Epilógus
A .NET 5 projekt fontos és izgalmas új irányt jelent a .NET számára. Látni fogod, hogy a .NET egyszerűbbé válik, de szélesebb körű funkciókkal és hasznossággal is rendelkezik. Minden új fejlesztés és funkció a .NET 5 része lesz, beleértve az új C# verziókat is.
Fényes jövőt látunk, ahol ugyanazokat a .NET API-kat és nyelveket használhatod széles körű alkalmazástípusok, operációs rendszerek és szilícium architektúrák célzásához. Visual Studio-ban, Visual Studio for Mac-en, Visual Studio Code-ban, Azure DevOps-ban vagy a parancssorban könnyű megváltoztatni a build konfigurációt, hogy különböző alkalmazásokat építsünk.
Eredeti link:A hiperlink bejelentkezés látható.
|