I dag annoncerer vi, at den næste udgivelse efter .NET Core 3.0 bliver .NET 5. Dette bliver den næste store udgivelse i .NET-serien.
I fremtiden vil der kun være ét .NET, hvormed du kan udvikle Windows, Linux, macOS, iOS, Android, tvOS, watchOS og WebAssembly, blandt andre.
Vi introducerer nye .NET API'er, runtime-funktioner og sprogfunktioner i .NET 5.
Med start i .NET Core-projektet har vi tilføjet omkring halvtreds tusind .NET Framework API'er til platformen. .NET Core 3.0 udfylder de fleste af de resterende funktionshuller i .NET Framework 4.8 og understøtter Windows Forms, WPF og Entity Framework 6. .NET 5 bygger videre på dette arbejde og udnytter de bedste funktioner fra .NET Core og Mono til at skabe en platform. Du kan bruge det til al moderne .NET-kode.
Vi har til hensigt at udgive .NET 5 i november 2020 og lancere den første preview i første halvdel af 2020. Det vil blive understøttet i fremtidige opdateringer til Visual Studio 2019, Visual Studio til Mac og Visual Studio Code.
.NET 5 = .NET Core vNext
.NET 5 er det næste skridt i .NET Core. Projektet har til formål at forbedre . NET:
- Byg et .NET runtime og framework, der kan bruges hvor som helst, med samlet runtime-adfærd og udvikleroplevelse.
- Ved at udnytte .NET Core fuldt ud, . NET Framework, Xamarin og Mono for at udvide .NET's muligheder.
- Ved at bygge produktet ud fra en enkelt kodebase kan udviklere (Microsoft og fællesskabet) arbejde sammen og udvide sammen for at forbedre alle scenarier.
Dette nye projekt og denne retning er et vigtigt vendepunkt for .NET. Med .NET 5 vil dine kode- og projektfiler være de samme, uanset hvilken type applikation du bygger. Hver app har adgang til de samme runtime-, API- og sprogfunktioner. Inkluderer også ydelsesforbedringer til CoreFX, som næsten dagligt bliver lavet.
Alt det, du elsker ved .NET Core, vil fortsat eksistere:
- Open source og fællesskabsorienteret på GitHub.
- Implementering på tværs af platforme.
- Understøttelse af platformspecifikke funktioner som Windows-formularer og WPF på Windows samt native bindings for hver native platform fra Xamarin.
- Høj ydeevne.
- Installer side om side.
- Små projektfiler (SDK-stil).
- Kompatibel med kommandolinjegrænseflader (CLI'er).
- Visual Studio, Visual Studio til Mac og Integration af Visual Studio Code.
Der er også nogle nye ting:
- Du får flere muligheder for din runtime-oplevelse (mere om det nedenfor).
- Java-interoperabilitet vil være tilgængelig på alle platforme.
- Flere operativsystemer vil understøtte Objective-C og Swift interoperabilitet.
- CoreFX vil blive udvidet til at understøtte forudgående tid (AOT) for .NET, et mindre fodaftryk og understøttelse af flere operativsystemer.
Vi udgiver .NET Core 3.0 i september i år, .NET 5 i november 2020, og derefter har vi til hensigt at udgive en større version af . NET:
Vi sprang version 4 over, fordi det ville forvirre brugere, der er bekendt med .NET Framework, som har eksisteret i lang tid med 4.x-serien. Derudover ønsker vi klart at kommunikere, at .NET 5 er fremtiden for .NET-platformen. At kalde det .NET 5 gør det til den højeste version, vi nogensinde har udgivet.
Vi benytter også lejligheden til at forenkle navngivningen. Vi mener, at hvis kun ét .NET er det bedste, behøver vi ikke et præciserende udtryk som "Core". Det kortere navn er en forenkling og formidler også budskabet om, at .NET 5 har ensartet funktionalitet og adfærd. Selvfølgelig kan du fortsætte med at bruge navnet ".NET Core", hvis du ønsker det.
Spilletidsoplevelse
Mono er den oprindelige platformoverskridende implementering af .NET. Det startede som et open source-alternativ til .NET Framework og gik over til mobilspecifikt i takt med populariteten af iPhone/iOS og Android-enheder. Mono er en runtime, der bruges som en del af Xamarin.
CoreCLR er en runtime, der bruges som en del af .NET Core. Den bruges primært til at understøtte cloud-applikationer, herunder Microsofts største tjeneste, og bruges nu også i Windows desktop-, IoT- og maskinlæringsapplikationer.
Sammenfattende deler .NET Core- og Mono-runtimerne mange ligheder (de er trods alt begge .NE-runtimes), men de har også værdifulde unikke funktioner. Det giver god mening at gøre det muligt at vælge den runtime-oplevelse, du ønsker. Vi gør CoreCLR og Mono udskiftelige med hinanden. Vi gør det så simpelt som at bygge en switch for at vælge mellem forskellige runtime-muligheder.
Følgende afsnit beskriver hovedfokus, vi planlægger at bruge til .NET 5. De giver et klart perspektiv på, hvordan vi planlægger at udvikle disse to runtimes individuelt og sammen.
Høj gennemstrømning og høj produktivitet
Fra begyndelsen var .NET afhængig af just-in-time compilere (JITs) til at konvertere mellemliggende sprogkode (IL) til optimeret maskinkode. Siden da har vi bygget en brancheførende JIT-baseret managed runtime med meget høj gennemstrømning og samtidig forbedrer udvikleroplevelsen, så programmering bliver hurtig og nem.
JIT er ideelt til langvarige cloud- og klientscenarier. De kan generere kode konfigureret til specifikke maskiner, inklusive specifikke CPU-instruktioner. JIT kan også gengenerere metoder under kørsel, en teknik der gør JIT hurtigere, samtidig med at der stadig er mulighed for at generere højt optimerede versioner af kode, hvis det bliver en ofte brugt metode.
Vores bestræbelser på at få ASP.NET Core til at køre hurtigere på Techpower-benchmarken er et godt eksempel på JIT's styrke og vores investering i CoreCLR. Vores indsats for at hærde .NET Core til containere er også et bevis på runtimens evne til dynamisk at tilpasse sig begrænsede miljøer.
Udviklerværktøjer er et andet godt eksempel på, hvordan JIT virkelig er godt, såsom dotnet-watch-værktøjer eller rediger og fortsæt. Værktøjer skal ofte kompilere og indlæse kode flere gange i en enkelt proces uden at genstarte, og det skal gøres meget hurtigt.
Udviklere, der bruger .NET Core eller .NET Framework, er primært afhængige af JIT. Derfor bør oplevelsen være velkendt.
Standardoplevelsen for de fleste .NET 5-fungerende scenarier vil bruge JIT-baserede CoreCLR-runtime. To bemærkelsesværdige undtagelser er iOS og klient Blazor (webassembly), da begge kræver forudgående (AOT) native kompilering.
Hurtig opstart, lille størrelse og lavt hukommelsesforbrug
Størstedelen af Mono-projektet har fokuseret på mobil og konsoller. En nøglefunktion og et resultat af projektet er .NET AOT-compileren, baseret på det brancheførende LLVM-compilerprojekt. Mono AOT-compileren gør det muligt at indbygge .NET-kode i en native kodeeksekverbar fil, der kan køre på en computer, ligesom C++-kode. AOT-kompilerede applikationer kan køre effektivt på mindre steder og udveksle gennemstrømning til opstart, når det er nødvendigt.
Blazor-projektet bruger allerede Mono AOT. Dette bliver et af de første projekter, der overgår til .NET 5. Vi bruger det som en af mulighederne for at bevise denne plan.
Der findes to typer AOT-løsninger:
- Kræver en løsning, der er 100% AOT-kompileret.
- Det meste kode er en AOT-kompileret løsning, men JIT eller fortolkere kan bruges til kodemønstre, der ikke er AOT-venlige (såsom generiske). Mono AOT understøtter begge tilfælde. Apple kræver den første AOT til iOS og nogle konsoller af sikkerhedsmæssige årsager. Den anden metode er en bedre mulighed, fordi den tilbyder fordelene ved AOT og undgår nogle af ulemperne.
.NET Native er vores AOT-kompilator til Windows UWP-applikationer og er også et eksempel på den første AOT-type, der er nævnt ovenfor. I denne specifikke implementering begrænser vi .NET API'et og de funktioner, du kan bruge. Vi lærte af denne erfaring, at AOT-løsninger skal dække alle aspekter af .NET API'er og mønstre.
AOT-kompilering er stadig påkrævet på iOS, webassembly og nogle konsoller. For applikationer, der kræver hurtigere opstart eller lavt footprint, gør vi AOT-kompilering til en mulighed.
Projektets fødsel
Vi startede dette projekt i december 2018 med et teknisk team i Boston. Designledere fra .NET-teamet (Mono/Xamarin og .NET Core) og Unity præsenterede en række tekniske kapaciteter og arkitektoniske retninger.
Vi driver nu dette projekt fremad som et team med et sæt leverancer. Vi har gjort store fremskridt med en række projekter siden december:
- Et minimumslag defineres, som definerer runtime-<-> managed code-laget med målet om at opnå >99% af CoreFX public code.
- MonoVM kan nu bruge CoreFX og dets klassebiblioteker.
- Kør alle CoreFX-tests på MonoVM med CoreFX-implementeringen.
- Kør ASP.NET Core 3.0-applikationer med MonoVM.
- Kør MonoDevelop på CoreCLR, og kør derefter Visual Studio til Mac.
Migrer til en enkelt. .NET-implementering rejser nogle vigtige spørgsmål: Hvad vil målrammen være? Er NuGet-pakkekompatibilitetsreglerne de samme? Hvilke arbejdsbelastninger bør .NET 5 SDK'en understøtte? Hvordan koder jeg for en specifik arkitektur? Har vi stadig brug for .NET Standard?
Vi arbejder på disse emner nu og vil snart dele designdokumentet, så du kan læse det og give feedback.
Epilog
.NET 5-projektet er en vigtig og spændende ny retning for .NET. Du vil se, at .NET bliver enklere, men også med et bredere udvalg af funktioner og nytteværdi. Alle nye udviklinger og funktioner vil være en del af .NET 5, inklusive nye C#-versioner.
Vi ser en lys fremtid, hvor man kan bruge de samme .NET API'er og sprog til at målrette en bred vifte af applikationstyper, operativsystemer og siliciumarkitekturer. I Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps eller kommandolinjen er det nemt at ændre build-konfigurationen for at bygge forskellige applikationer.
Originalt link:Hyperlink-login er synlig.
|
Opslået på 07/05/2019 09.41.27
|
|
|
|
