I dag kunngjør vi at neste utgivelse etter .NET Core 3.0 vil være .NET 5. Dette blir den neste store utgivelsen i .NET-serien.
I fremtiden vil det bare være én .NET, hvor du kan utvikle Windows, Linux, macOS, iOS, Android, tvOS, watchOS og WebAssembly, blant andre.
Vi introduserer nye .NET-API-er, kjøretidsfunksjoner og språkfunksjoner i .NET 5.
Fra og med .NET Core-prosjektet har vi lagt til omtrent femti tusen .NET Framework-API-er på plattformen. .NET Core 3.0 fyller de fleste av de gjenværende funksjonsgapene i .NET Framework 4.8, og støtter Windows Forms, WPF og Entity Framework 6. .NET 5 bygger videre på dette arbeidet og utnytter de beste funksjonene fra .NET Core og Mono for å skape en plattform. Du kan bruke det til all moderne .NET-kode.
Vi har til hensikt å lansere .NET 5 i november 2020 og lansere den første forhåndsvisningen i første halvdel av 2020. Det vil bli støttet i fremtidige oppdateringer for Visual Studio 2019, Visual Studio for Mac og Visual Studio Code.
.NET 5 = .NET Core vNext
.NET 5 er neste steg i .NET Core. Prosjektet har som mål å forbedre . NETT:
- Bygg en .NET-kjøretid og rammeverk som kan brukes hvor som helst, med enhetlig kjøretidsatferd og utviklererfaring.
- Ved å utnytte .NET Core fullt ut, . NET Framework, Xamarin og Mono for å utvide mulighetene til .NET.
- Ved å bygge produktet fra én enkelt kodebase, kan utviklere (Microsoft og fellesskapet) samarbeide og utvide sammen for å forbedre alle scenarioer.
Dette nye prosjektet og retningen er et viktig vendepunkt for .NET. Med .NET 5 vil koden og prosjektfilene dine være de samme uansett hvilken type applikasjon du bygger. Hver app har tilgang til samme runtime-, API- og språkfunksjoner. Inkluderer også ytelsesforbedringer til CoreFX, som gjøres nesten daglig.
Alt du elsker med .NET Core vil fortsette å eksistere:
- Åpen kildekode og fellesskapsorientert på GitHub.
- Plattformuavhengig implementering.
- Støtte ved å utnytte plattformspesifikke funksjoner som Windows-skjemaer og WPF på Windows, samt native bindings for hver native plattform fra Xamarin.
- Høy ytelse.
- Installer side om side.
- Små prosjektfiler (SDK-stil).
- Kompatibel med kommandolinjegrensesnitt (CLI).
- Visual Studio, Visual Studio for Mac, og Visual Studio Code-integrasjon.
Det er også noen nye ting:
- Du vil ha flere alternativer for din kjøretidsopplevelse (mer om det nedenfor).
- Java-interoperabilitet vil være tilgjengelig på alle plattformer.
- Flere operativsystemer vil støtte interoperabilitet mellom Objective-C og Swift.
- CoreFX vil bli utvidet for å støtte forhåndsvisning (AOT) for .NET, et mindre fotavtrykk og støtte for flere operativsystemer.
Vi vil slippe .NET Core 3.0 i september i år, .NET 5 i november 2020, og deretter har vi planer om å gi ut en større versjon av . NETT:
Vi hoppet over versjon 4 fordi det ville forvirre brukere som er kjent med .NET Framework, som har eksistert lenge med 4.x-serien. I tillegg ønsker vi tydelig å kommunisere at .NET 5 er fremtiden for .NET-plattformen. Å kalle det .NET 5 gjør det til den høyeste versjonen vi noen gang har gitt ut.
Vi benytter også anledningen til å forenkle navngivningen. Vi mener at hvis bare én .NET er best, trenger vi ikke et oppklarende begrep som «Core». Det kortere navnet er en forenkling og formidler også budskapet om at .NET 5 har ensartet funksjonalitet og oppførsel. Selvfølgelig kan du fortsette å bruke navnet ".NET Core" hvis du ønsker det.
Kjøretidsopplevelse
Mono er den opprinnelige plattformuavhengige implementeringen av .NET. Det startet som et åpen kildekode-alternativ til .NET Framework og gikk over til mobilspesifikt med populariteten til iPhone/iOS og Android-enheter. Mono er en runtime som brukes som en del av Xamarin.
CoreCLR er en runtime som brukes som en del av .NET Core. Den brukes primært til å støtte skyapplikasjoner, inkludert Microsofts største tjeneste, og brukes nå også i Windows-skrivebord, IoT og maskinlæringsapplikasjoner.
Oppsummert deler .NET Core- og Mono-runtimene mange likheter (tross alt er de begge .NE-runtime), men de har også verdifulle unike egenskaper. Det gir mye mening å gjøre det mulig å velge den kjøretidsopplevelsen du ønsker. Vi gjør CoreCLR og Mono utskiftbare med hverandre. Vi gjør det så enkelt som å bygge en switch for å velge mellom ulike runtime-alternativer.
Følgende avsnitt beskriver hovedfokuset vi planlegger å bruke for .NET 5. De gir et klart perspektiv på hvordan vi planlegger å utvikle disse to runtimene individuelt og sammen.
Høy gjennomstrømning og høy produktivitet
Fra starten var .NET avhengig av just-in-time-kompilatorer (JITs) for å konvertere mellomliggende språk (IL) kode til optimalisert maskinkode. Siden da har vi bygget en bransjeledende JIT-basert styrt kjøretid med svært høy gjennomstrømning og som også forbedrer utvikleropplevelsen, noe som gjør programmering rask og enkel.
JIT er ideelt for langvarige sky- og klientscenarier. De kan generere kode konfigurert for spesifikke maskiner, inkludert spesifikke CPU-instruksjoner. JIT kan også regenerere metoder under kjøring, en teknikk som gjør JIT raskere, samtidig som det fortsatt har mulighet til å generere svært optimaliserte versjoner av kode hvis det blir en ofte brukt metode.
Våre anstrengelser for å få ASP.NET Core til å kjøre raskere på Techpower-benchmarken er et godt eksempel på kraften i JIT og vår investering i CoreCLR. Våre anstrengelser for å gjøre .NET Core hardere for containere er også et bevis på runtimens evne til dynamisk å tilpasse seg begrensede miljøer.
Utviklerverktøy er et annet godt eksempel på hvordan JIT virkelig er bra, som dotnet-overvåkingsverktøy eller rediger og fortsett. Verktøy må ofte kompilere og laste kode flere ganger i én prosess uten å starte på nytt, og må gjøre dette veldig raskt.
Utviklere som bruker .NET Core eller .NET Framework er primært avhengige av JIT. Derfor bør opplevelsen være kjent.
Standardopplevelsen for de fleste .NET 5-fungerende scenarioer vil bruke JIT-basert CoreCLR-runtime. To bemerkelsesverdige unntak er iOS og klient Blazor (webassembly), da begge krever forhåndskompilering (AOT) av egen kompilering.
Rask oppstart, liten størrelse og lavt minneforbruk
Mesteparten av Mono-prosjektet har fokusert på mobil og konsoller. En nøkkelfunksjon og et resultat av prosjektet er .NET AOT-kompilatoren basert på det bransjeledende LLVM-kompilatorprosjektet. Mono AOT-kompilatoren gjør det mulig å bygge .NET-kode inn i en native kodekjørbar fil som kan kjøres på en datamaskin, akkurat som C++-kode. AOT-kompilerte applikasjoner kan kjøre effektivt på mindre steder og utveksle gjennomstrømning for oppstart når det trengs.
Blazor-prosjektet bruker allerede Mono AOT. Dette vil være et av de første prosjektene som går over til .NET 5. Vi bruker det som et av alternativene for å bevise denne planen.
Det finnes to typer AOT-løsninger:
- Krever en løsning som er 100 % AOT-kompilert.
- Det meste av koden er en AOT-kompilert løsning, men JIT eller tolker kan brukes for kodemønstre som ikke er AOT-vennlige (som generiske). Mono AOT støtter begge tilfellene. Apple krever den første AOT for iOS og noen konsoller av sikkerhetsgrunner. Den andre metoden er et bedre alternativ fordi den tilbyr fordelene med AOT og unngår noen av ulempene.
.NET Native er vår AOT-kompilator for Windows UWP-applikasjoner, og er også et eksempel på den første AOT-typen nevnt ovenfor. I denne spesifikke implementeringen begrenser vi .NET API-et og funksjonene du kan bruke. Vi lærte av denne erfaringen at AOT-løsninger må dekke alle aspekter av .NET-API-er og mønstre.
AOT-kompilering er fortsatt nødvendig på iOS, webassembly og noen konsoller. For applikasjoner som krever raskere oppstart eller lav fotavtrykk, vil vi gjøre AOT-kompilering til et alternativ.
Prosjektets fødsel
Vi startet dette prosjektet i desember 2018 med et teknisk team i Boston. Designledere fra .NET-teamet (Mono/Xamarin og .NET Core) og Unity presenterte en rekke tekniske muligheter og arkitektoniske retninger.
Vi driver nå dette prosjektet fremover som et team med et sett leveranser. Vi har gjort mye fremgang med flere prosjekter siden desember:
- Et minimumslag defineres som definerer kjøretids-<-> administrert kodelag med mål om å oppnå >99 % av CoreFX offentlig kode.
- MonoVM kan nå bruke CoreFX og dets klassebiblioteker.
- Kjør alle CoreFX-tester på MonoVM med CoreFX-implementasjonen.
- Kjør ASP.NET Core 3.0-applikasjoner med MonoVM.
- Kjør MonoDevelop på CoreCLR, og kjør deretter Visual Studio for Mac.
Migrer til en enkelt. .NET-implementering reiser noen viktige spørsmål: Hva vil målrammeverket være? Er NuGet-pakkekompatibilitetsreglene de samme? Hvilke arbeidsbelastninger bør .NET 5 SDK støtte? Hvordan koder jeg for en spesifikk arkitektur? Trenger vi fortsatt .NET Standard?
Vi jobber med disse spørsmålene nå og vil snart dele designdokumentet slik at du kan lese det og gi tilbakemelding.
Epilog
.NET 5-prosjektet er en viktig og spennende ny retning for .NET. Du vil se at .NET blir enklere, men også med et bredere spekter av funksjoner og nytte. Alle nye utviklinger og funksjoner vil være en del av .NET 5, inkludert nye C#-versjoner.
Vi ser en lys fremtid hvor du kan bruke de samme .NET-API-ene og språkene for å målrette et bredt spekter av applikasjonstyper, operativsystemer og silisiumarkitekturer. I Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps eller kommandolinjen er det enkelt å endre byggekonfigurasjonen for å lage forskjellige applikasjoner.
Original lenke:Innloggingen med hyperkoblingen er synlig.
|
Publisert på 07.05.2019 09:41:27
|
|
|
|
