Vandaag kondigen we aan dat de volgende release na .NET Core 3.0 .NET 5 zal zijn. Dit wordt de volgende grote release in de .NET-serie.
In de toekomst zal er slechts één .NET zijn, waarmee je Windows, Linux, macOS, iOS, Android, tvOS, watchOS en WebAssembly kunt ontwikkelen, onder andere.
We introduceren nieuwe .NET API's, runtime-functies en taalfuncties in .NET 5.
Te beginnen met het .NET Core-project hebben we ongeveer vijftigduizend .NET Framework API's aan het platform toegevoegd. .NET Core 3.0 vult de meeste resterende functietekorten van .NET Framework 4.8 op, met ondersteuning voor Windows Forms, WPF en Entity Framework 6. .NET 5 bouwt voort op dit werk en maakt gebruik van de beste functies van .NET Core en Mono om een platform te creëren. Je kunt het gebruiken voor alle moderne .NET-code.
We zijn van plan .NET 5 uit te brengen in november 2020 en de eerste preview te lanceren in de eerste helft van 2020. Het zal worden ondersteund in toekomstige updates voor Visual Studio 2019, Visual Studio voor Mac en Visual Studio Code.
.NET 5 = .NET Core vNext
.NET 5 is de volgende stap in .NET Core. Het project heeft als doel de . NET:
- Bouw een .NET runtime en framework dat overal gebruikt kan worden, met gezamenlijk runtime-gedrag en ontwikkelervaring.
- Door optimaal gebruik te maken van .NET Core, . NET Framework, Xamarin en Mono om de mogelijkheden van .NET uit te breiden.
- Door het product te bouwen vanuit één codebasis, kunnen ontwikkelaars (Microsoft en de community) samenwerken en uitbreiden om alle scenario's te verbeteren.
Dit nieuwe project en deze richting is een belangrijk keerpunt voor .NET. Met .NET 5 blijven je code- en projectbestanden hetzelfde, ongeacht welk type applicatie je bouwt. Elke app heeft toegang tot dezelfde runtime-, API- en taalfuncties. Bevat ook prestatieverbeteringen voor CoreFX, die bijna dagelijks worden doorgevoerd.
Alles wat je zo mooi vindt aan .NET Core blijft bestaan:
- Open source en communitygericht op GitHub.
- Cross-platform implementatie.
- Ondersteuning voor het benutten van platformspecifieke functies zoals Windows-formulieren en WPF op Windows en native bindings voor elk native platform vanuit Xamarin.
- Hoge prestaties.
- Installeer naast elkaar.
- Kleine projectbestanden (SDK-stijl).
- Compatibel met commandoregelinterfaces (CLI's).
- Visual Studio, Visual Studio voor Mac en Visual Studio Code-integratie.
Er zijn ook enkele nieuwe dingen:
- Je krijgt meer opties voor je runtime-ervaring (daarover hieronder meer).
- Java-interoperabiliteit zal op alle platforms beschikbaar zijn.
- Meerdere besturingssystemen zullen Objective-C en Swift-interoperabiliteit ondersteunen.
- CoreFX zal worden uitgebreid om vooruit-of-time (AOT) voor .NET te ondersteunen, een kleinere footprint en ondersteuning voor meer besturingssystemen.
We zullen .NET Core 3.0 uitbrengen in september van dit jaar, .NET 5 in november 2020, en daarna zijn we van plan een grote versie van de uit te brengen. NET:
We hebben versie 4 overgeslagen omdat het gebruikers zou verwarren die bekend zijn met het .NET Framework, dat al lange tijd bestaat met de 4.x-serie. Daarnaast willen we duidelijk communiceren dat .NET 5 de toekomst is van het .NET-platform. Het noemen van .NET 5 maakt het de hoogste versie die we ooit hebben uitgebracht.
We grijpen deze gelegenheid ook aan om de naamgeving te vereenvoudigen. We denken dat als slechts één .NET het beste is, we geen verduidelijkende term als "Core" nodig hebben. De kortere naam is een vereenvoudiging en geeft ook de boodschap over dat .NET 5 uniforme functionaliteit en gedrag heeft. Natuurlijk kun je de naam ".NET Core" blijven gebruiken als je wilt.
Runtime-ervaring
Mono is de oorspronkelijke cross-platform implementatie van .NET. Het begon als een open-source alternatief voor het .NET Framework en ging over naar mobiel-specifiek met de populariteit van iPhone/iOS- en Android-apparaten. Mono is een runtime die wordt gebruikt als onderdeel van Xamarin.
CoreCLR is een runtime die wordt gebruikt als onderdeel van .NET Core. Het wordt voornamelijk gebruikt ter ondersteuning van cloudapplicaties, waaronder Microsofts grootste dienst, en wordt nu ook gebruikt in Windows-desktop-, IoT- en machine learning-applicaties.
Samenvattend delen de .NET Core- en Mono-runtimes veel overeenkomsten (het zijn immers allebei .NE-runtimes), maar ze hebben ook waardevolle unieke kenmerken. Het is heel logisch om het mogelijk te maken om de runtime-ervaring te kiezen die je wilt. We maken CoreCLR en Mono uitwisselbaar met elkaar. We maken het zo simpel als het bouwen van een switch om te kiezen tussen verschillende runtime-opties.
De volgende secties beschrijven de hoofdfocus die we van plan zijn te gebruiken voor .NET 5. Ze bieden een duidelijk perspectief op hoe we van plan zijn deze twee runtimes afzonderlijk en samen te laten evolueren.
Hoge doorvoer en hoge productiviteit
Vanaf het begin vertrouwde .NET op just-in-time compilers (JITs) om intermediate language (IL) code om te zetten in geoptimaliseerde machinecode. Sindsdien hebben we een toonaangevende JIT-gebaseerde managed runtime gebouwd met een zeer hoge doorvoersnelheid en ook de ontwikkelaarservaring verbetert, waardoor programmeren snel en eenvoudig wordt.
JIT is ideaal voor langlopende cloud- en klantscenario's. Ze kunnen code genereren die is geconfigureerd voor specifieke machines, inclusief specifieke CPU-instructies. JIT kan ook methoden tijdens runtime opnieuw genereren, een techniek die JIT sneller maakt, terwijl er toch de optie is om sterk geoptimaliseerde versies van code te genereren als het een veelgebruikte methode wordt.
Onze inspanningen om ASP.NET Core sneller te laten draaien op de Techpower-benchmark zijn een uitstekend voorbeeld van de kracht van JIT en onze investering in CoreCLR. Onze inspanningen om .NET Core voor containers te versterken zijn ook een bewijs van het vermogen van de runtime om zich dynamisch aan te passen aan beperkte omgevingen.
Ontwikkelaarstools zijn een ander goed voorbeeld van hoe JIT echt geweldig is, zoals dotnet watch tools of edit and continue. Tools moeten vaak code meerdere keren compileren en laden in één proces zonder opnieuw op te starten, en dat heel snel.
Ontwikkelaars die .NET Core of .NET Framework gebruiken, vertrouwen voornamelijk op JIT. Daarom moet de ervaring vertrouwd zijn.
De standaardervaring voor de meeste .NET 5-werkscenario's zal de JIT-gebaseerde CoreCLR-runtime gebruiken. Twee opvallende uitzonderingen zijn iOS en client Blazor (webassembly), omdat beide vooraf (AOT) native compilatie vereisen.
Snelle opstart, kleine footprint en laag geheugengebruik
Het grootste deel van het Mono-project richt zich op mobiel en consoles. Een belangrijk kenmerk en resultaat van het project is de .NET AOT-compiler, gebaseerd op het toonaangevende LLVM-compilerproject. De Mono AOT-compiler maakt het mogelijk .NET-code in een native code-uitvoerbaar bestand te bouwen dat op een computer kan draaien, net als C++-code. AOT-gecompileerde applicaties kunnen efficiënt draaien op kleinere locaties en doorvoer uitwisselen voor opstart wanneer dat nodig is.
Het Blazor-project gebruikt al Mono AOT. Dit zal een van de eerste projecten zijn die overstappen naar .NET 5. We gebruiken het als een van de opties om dit plan te bewijzen.
Er zijn twee soorten AOT-oplossingen:
- Vereist een oplossing die 100% AOT-gecompileerd is.
- De meeste code is een AOT-gecompileerde oplossing, maar JIT of interpreters kunnen worden gebruikt voor codepatronen die niet AOT-vriendelijk zijn (zoals generieke). Mono AOT ondersteunt beide gevallen. Apple vereist de eerste AOT voor iOS en sommige consoles om veiligheidsredenen. De tweede methode is een betere optie omdat deze de voordelen van AOT biedt en enkele nadelen vermijdt.
.NET Native is onze AOT-compiler voor Windows UWP-applicaties en is ook een voorbeeld van het eerste hierboven genoemde AOT-type. In deze specifieke implementatie beperken we de .NET API en de functies die je kunt gebruiken. We hebben uit deze ervaring geleerd dat AOT-oplossingen alle aspecten van .NET API's en patronen moeten dekken.
AOT-compilatie is nog steeds vereist op iOS, webassembly en sommige consoles. Voor applicaties die sneller opstarten of een lage footprint vereisen, maken we AOT-compilatie een optie.
De geboorte van het project
We zijn dit project gestart in december 2018 met een technisch team in Boston. Ontwerpleiders van het .NET-team (Mono/Xamarin en .NET Core) en Unity presenteerden diverse technische mogelijkheden en architecturale richtingen.
We brengen dit project nu als team vooruit met een reeks leverresultaten. We hebben sinds december veel vooruitgang geboekt met een aantal projecten:
- Er wordt een minimumlaag gedefinieerd die de runtime <-> managed codelaag definieert met als doel het bereiken van >99% van de publieke CoreFX-code.
- MonoVM kan nu CoreFX en de bijbehorende klassebibliotheken gebruiken.
- Voer alle CoreFX-tests uit op MonoVM met de CoreFX-implementatie.
- Voer ASP.NET Core 3.0-applicaties uit met MonoVM.
- Voer MonoDevelop uit op CoreCLR en gebruik daarna Visual Studio voor Mac.
Migreren naar één . De implementatie van .NET roept enkele belangrijke vragen op: Wat zal het doelkader zijn? Zijn de compatibiliteitsregels van de NuGet-pakketten hetzelfde? Welke workloads zou de .NET 5 SDK moeten ondersteunen? Hoe codeer ik voor een specifieke architectuur? Hebben we nog steeds .NET Standard nodig?
We werken nu aan deze kwesties en zullen binnenkort het ontwerpdocument delen zodat u het kunt lezen en feedback kunt geven.
Epiloog
Het .NET 5-project is een belangrijke en spannende nieuwe richting voor .NET. Je zult zien dat .NET eenvoudiger wordt, maar ook een breder scala aan functies en bruikbaarheid. Alle nieuwe ontwikkelingen en functies maken deel uit van .NET 5, inclusief nieuwe C#-versies.
We zien een mooie toekomst waarin je dezelfde .NET API's en talen kunt gebruiken om een breed scala aan applicatietypes, besturingssystemen en siliciumarchitecturen te targeten. In Visual Studio, Visual Studio voor Mac, Visual Studio Code, Azure DevOps of de commandoregel is het eenvoudig om de buildconfiguratie aan te passen om verschillende applicaties te bouwen.
Originele link:De hyperlink-login is zichtbaar.
|
Geplaatst op 07-05-2019 09:41:27
|
|
|
|
