Idag meddelar vi att nästa version efter .NET Core 3.0 kommer att vara .NET 5. Detta blir nästa stora utgåva i .NET-serien.
I framtiden kommer det bara att finnas ett .NET, med vilket du kan utveckla Windows, Linux, macOS, iOS, Android, tvOS, watchOS och WebAssembly, bland andra.
Vi introducerar nya .NET-API:er, runtime-funktioner och språkfunktioner i .NET 5.
Med start i .NET Core-projektet har vi lagt till cirka femtio tusen .NET Framework-API:er till plattformen. .NET Core 3.0 fyller de flesta av de återstående funktionsluckorna i .NET Framework 4.8 och stödjer Windows Forms, WPF och Entity Framework 6. .NET 5 bygger vidare på detta arbete och utnyttjar de bästa funktionerna från .NET Core och Mono för att skapa en plattform. Du kan använda det för all modern .NET-kod.
Vi planerar att släppa .NET 5 i november 2020 och lansera den första förhandsvisningen under första halvan av 2020. Det kommer att stödjas i framtida uppdateringar för Visual Studio 2019, Visual Studio för Mac och Visual Studio Code.
.NET 5 = .NET Core vNext
.NET 5 är nästa steg i .NET Core. Projektet syftar till att förbättra . NÄT:
- Bygg en .NET-runtime och ramverk som kan användas var som helst, med enhetligt körbeteende och utvecklarupplevelse.
- Genom att utnyttja .NET Core fullt ut, . NET Framework, Xamarin och Mono för att utöka .NET:s kapacitet.
- Genom att bygga produkten från en enda kodbas kan utvecklare (Microsoft och communityn) arbeta tillsammans och utöka tillsammans för att förbättra alla scenarier.
Detta nya projekt och denna riktning är en stor vändpunkt för .NET. Med .NET 5 kommer din kod och projektfiler att vara desamma oavsett vilken typ av applikation du bygger. Varje app har tillgång till samma runtime-, API- och språkfunktioner. Inkluderar även prestandaförbättringar för CoreFX, som görs nästan dagligen.
Allt du älskar med .NET Core kommer att fortsätta existera:
- Öppen källkod och community-orienterad på GitHub.
- Plattformsoberoende implementering.
- Stöd för att utnyttja plattformsspecifika funktioner som Windows-formulär och WPF på Windows samt inbyggda bindningar för varje inhemsk plattform från Xamarin.
- Hög prestanda.
- Installera sida vid sida.
- Små projektfiler (SDK-stil).
- Kompatibel med kommandoradsgränssnitt (CLI).
- Visual Studio, Visual Studio för Mac och Visual Studio Code-integration.
Det finns också några nya saker:
- Du får fler alternativ för din runtime-upplevelse (mer om det nedan).
- Java-interoperabilitet kommer att finnas tillgänglig på alla plattformar.
- Flera operativsystem kommer att stödja interoperabilitet mellan Objective-C och Swift.
- CoreFX kommer att utökas för att stödja ahead-of-time (AOT) för .NET, ett mindre fotavtryck och stöd för fler operativsystem.
Vi kommer att släppa .NET Core 3.0 i september i år, .NET 5 i november 2020, och sedan planerar vi att släppa en större version av . NÄT:
Vi hoppade över version 4 eftersom det skulle förvirra användare som är bekanta med .NET Framework, som har funnits länge med 4.x-serien. Dessutom vill vi tydligt kommunicera att .NET 5 är framtiden för .NET-plattformen. Att kalla det .NET 5 gör det till den högsta versionen vi någonsin släppt.
Vi tar också tillfället i akt att förenkla namngivningen. Vi tror att om bara en .NET är bäst, behöver vi inte en förtydligande term som "Core". Det kortare namnet är en förenkling och förmedlar också budskapet att .NET 5 har enhetlig funktionalitet och beteende. Självklart kan du fortsätta använda namnet ".NET Core" om du vill.
Spelupplevelse
Mono är den ursprungliga plattformsoberoende implementationen av .NET. Det började som ett öppet alternativ till .NET Framework och övergick till mobilspecifikt i takt med att iPhone/iOS- och Android-enheter blev populära. Mono är en runtime som används som en del av Xamarin.
CoreCLR är en runtime som används som en del av .NET Core. Det används främst för att stödja molnapplikationer, inklusive Microsofts största tjänst, och används nu även i Windows-skrivbords-, IoT- och maskininlärningsapplikationer.
Sammanfattningsvis delar .NET Core- och Mono-runtimes många likheter (de är ju båda .NE-runtimes), men de har också värdefulla unika egenskaper. Det är mycket logiskt att göra det möjligt att välja den runtime-upplevelse du vill ha. Vi gör CoreCLR och Mono utbytbara med varandra. Vi gör det så enkelt som att bygga en switch för att välja mellan olika runtime-alternativ.
Följande avsnitt beskriver huvudfokus vi planerar att använda för .NET 5. De ger en tydlig bild av hur vi planerar att utveckla dessa två runtimes individuellt och tillsammans.
Hög genomströmning och hög produktivitet
Från början förlitade sig .NET på just-in-time-kompilatorer (JITs) för att konvertera mellanliggande språk (IL) till optimerad maskinkod. Sedan dess har vi byggt en branschledande JIT-baserad managed runtime med mycket hög genomströmning och som också förbättrar utvecklarupplevelsen, vilket gör programmering snabb och enkel.
JIT är idealiskt för långvariga moln- och klientscenarier. De kan generera kod konfigurerad för specifika maskiner, inklusive specifika CPU-instruktioner. JIT kan också återskapa metoder vid körning, en teknik som gör JIT snabbare, samtidigt som man har möjlighet att generera mycket optimerade versioner av kod om den blir en ofta använd metod.
Våra ansträngningar att få ASP.NET Core att gå snabbare på Techpower-benchmarken är ett utmärkt exempel på JIT:s kraft och vår investering i CoreCLR. Våra ansträngningar att härda .NET Core för containrar är också ett bevis på runtimens förmåga att dynamiskt anpassa sig till begränsade miljöer.
Utvecklarverktyg är ett annat bra exempel på hur JIT verkligen är bra, som dotnet watch tools eller edit and continue. Verktyg behöver ofta kompilera och ladda kod flera gånger i en och samma process utan att behöva starta om, och måste göra detta mycket snabbt.
Utvecklare som använder .NET Core eller .NET Framework förlitar sig främst på JIT. Därför bör upplevelsen vara bekant.
Standardupplevelsen för de flesta .NET 5-fungerande scenarier kommer att använda JIT-baserade CoreCLR-runtime. Två anmärkningsvärda undantag är iOS och klient Blazor (webbassembly), eftersom båda kräver ahead-of-time (AOT) inbyggd kompilering.
Snabb uppstart, liten fotavtryck och låg minnesanvändning
Största delen av Mono-projektet har fokuserat på mobiler och konsoler. En nyckelfunktion och ett resultat av projektet är .NET AOT-kompilatorn baserad på det branschledande LLVM-kompilatorprojektet. Mono AOT-kompilatorn tillåter att .NET-kod byggs in i en inbyggd kodexekverbar fil som kan köras på en dator, precis som C++-kod. AOT-kompilerade applikationer kan köras effektivt på mindre platser och utbyta genomströmning för uppstart vid behov.
Blazor-projektet använder redan Mono AOT. Detta kommer att vara ett av de första projekten som övergår till .NET 5. Vi använder det som ett av alternativen för att bevisa denna plan.
Det finns två typer av AOT-lösningar:
- Kräver en lösning som är 100 % AOT-kompilerad.
- De flesta kod är en AOT-kompilerad lösning, men JIT eller tolkar kan användas för kodmönster som inte är AOT-vänliga (såsom generiska varianter). Mono AOT stöder båda fallen. Apple kräver den första AOT för iOS och vissa konsoler av säkerhetsskäl. Den andra metoden är ett bättre alternativ eftersom den erbjuder fördelarna med AOT och undviker vissa nackdelar.
.NET Native är vår AOT-kompilator för Windows UWP-applikationer och är också ett exempel på den första AOT-typen som nämnts ovan. I just denna implementation begränsar vi .NET-API:et och de funktioner du kan använda. Vi lärde oss av denna erfarenhet att AOT-lösningar behöver täcka alla aspekter av .NET API:er och mönster.
AOT-kompilering krävs fortfarande på iOS, webbassembler och vissa konsoler. För applikationer som kräver snabbare uppstart eller låg fotavtryck gör vi AOT-kompilering till ett alternativ.
Projektets födelse
Vi startade detta projekt i december 2018 med ett tekniskt team i Boston. Designledare från .NET-teamet (Mono/Xamarin och .NET Core) och Unity presenterade en mängd tekniska funktioner och arkitektoniska riktningar.
Vi driver nu detta projekt framåt som ett team med en uppsättning leveranser. Vi har gjort stora framsteg med flera projekt sedan december:
- Ett minimilager definieras som definierar körtids-<-> hanterad kodlager med målet att uppnå >99 % av CoreFX:s publika kod.
- MonoVM kan nu använda CoreFX och dess klassbibliotek.
- Kör alla CoreFX-tester på MonoVM med CoreFX-implementationen.
- Kör ASP.NET Core 3.0-applikationer med MonoVM.
- Kör MonoDevelop på CoreCLR, och kör sedan Visual Studio för Mac.
Migrera till en enda . .NET-implementering väcker några viktiga frågor: Vad kommer målramverket att vara? Är NuGet-paketens kompatibilitetsregler desamma? Vilka arbetsbelastningar bör .NET 5 SDK stödja? Hur kodar jag för en specifik arkitektur? Behöver vi fortfarande .NET Standard?
Vi arbetar med dessa frågor nu och kommer snart att dela designdokumentet så att du kan läsa det och ge feedback.
Epilog
.NET 5-projektet är en viktig och spännande ny riktning för .NET. Du kommer att se att .NET blir enklare, men också med ett bredare utbud av funktioner och användbarhet. Alla nya utvecklingar och funktioner kommer att ingå i .NET 5, inklusive nya C#-versioner.
Vi ser en ljus framtid där man kan använda samma .NET-API:er och språk för att rikta in sig på ett brett spektrum av applikationstyper, operativsystem och kiselarkitekturer. I Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps eller kommandoraden är det enkelt att ändra byggkonfigurationen för att bygga olika applikationer.
Originallänk:Inloggningen med hyperlänken är synlig.
|
Publicerad på 2019-05-07 09:41:27
|
|
|
|
