Et av nøkkeltemaene i Microsofts utviklerstrategi for 2020 er kanskje best tenkt på som skiftet mellom generasjoner. Det er en relativt jevn overlevering, innrammet som en forening av gamle og nye måter å jobbe på. Men til slutt, enten det er Project Reunion, WinUI 3 eller lanseringen av .NET 5, går den nye teknologien fremover og etterlater den gamle.
Det er ikke dårlig. Vi utvikler nye måter å gjøre ting på av mange grunner, men de samles ofte rundt ett nøkkelpunkt: Den nye måten er bedre. Det løser problemer som gamle verktøy ikke kunne, og svarer på nye spørsmål som ikke ble spurt da den opprinnelige løsningen ble definert.
Et nytt .NET for en ny verden
Alle disse grunnene kommer sammen i overgangen fra .NET Framework til .NET 5. For tjue år siden da det opprinnelige .NET Framework ble definert, bygde vi monolitiske klient-serverapplikasjoner i tett definerte IT-miljøer. Nå bygger vi en blanding av lette distribuerte mikrotjenester og mobilapper på tvers av plattformer, og bruker raskt skiftende infrastruktur. Det er, til tross for klisjeen, en helt ny verden.
.NET Core ble designet for denne måten å jobbe på; plattform fra tidlig i livet og ment å støtte nye, sky-første mobilapplikasjoner samt tradisjonelle .NET utviklingsmønstre og praksis. Den plukket opp flere og flere API-er gjennom tre store utgivelser, og da .NET Standard-bibliotekene begynte å tilby et felles mål for kode som gjorde det lettere å dele prosjekter på tvers av det, .NET Framework og Xamarin.
.NET 5: En vei for fremtidig utvikling
Teknisk sett burde denne nye utgaven være .NET Core 4, men Microsoft hopper over et versjonsnummer for å unngå forveksling med den nåværende utgivelsen av .NET Framework. Samtidig, å flytte til et høyere versjonsnummer og slippe Core fra navnet, indikerer at dette er neste trinn for all .NET-utvikling. To prosjekter beholder fortsatt kjernenavnet: ASP.NET Core 5.0 og Entity Framework Core 5, siden eldre prosjekter med samme versjonsnummer fortsatt eksisterer.
Det er en viktig milepæl, som markerer punktet der du må vurdere å starte alle nye prosjekter i .NET 5 og flytte eksisterende kode fra. NET Framework. Selv om Microsoft ikke fjerner støtte fra .NET Framework, er den i vedlikeholdsmodus og får ikke nye funksjoner i fremtidige punktutgivelser. Alle nye API-er og samfunnsutvikling vil være i .NET 5 (og 2021s langsiktige støtte. NET 6).
Noen kjente teknologier som webskjemaer og Windows Communication Foundation blir avviklet i .NET 5. Hvis du fortsatt bruker dem, er det best å være på .NET Framework 4 for nå og planlegge en migrering til nyere støttede teknologier, for eksempel som ASP.NET's Razor Pages eller gRPC. Det er planer for fellestøtte for alternative rammer som vil tilby lignende API-er, men å jobbe med nyere tilnærminger vil hjelpe fremtidssikker kode og gjøre det lettere å jobbe på tvers av plattformer.
Et litt forvirrende aspekt av .NET 5 er hvordan det fungerer med. NET Standard-biblioteker. NET-koden trenger ikke å henvise direkte til dem, men de er nå en delmengde av .NET 5 target framework moniker (TFM). Denne nye TFM erstatter den gamle netcoreapp og nettstandard TFM-er, men hvis du skriver kode som må deles på tvers av rammeverk, kan du fortsatt bruke .NET Standard 2.0 TFM for kompatibilitetsformål. I de fleste tilfeller vil du imidlertid sannsynligvis bare jobbe i et .NET 5-miljø slik at du trygt kan holde fast ved en netto5.0 TFM-erklæring.
Komme i gang med .NET 5
.NET 5.0 fortsetter å være vert for det samme kjente settet med språk, inkludert nye versjoner av både C # og F #. Disse legger til mange nye funksjoner og kommer som en del av Visual Studio 16.8 eller med den oppdaterte C # Visual Studio Code-utvidelsen. Microsoft har flyttet rammeverket og alle implementeringene, som mye av Mono, til et enkelt GitHub-lager, som konsoliderer utviklingen og sørger for at alle versjoner har de samme underliggende funksjonene. Når Microsoft flytter til .NET 6, vil det hente inn andre implementeringer på høyere nivå, inkludert Xamarin.
Den nye .NET er fortsatt basert på just-in-time kompilerteknikker utviklet for den opprinnelige Common Language Runtime. Den nye CoreCLR fortsetter å forbedre ytelsen mens du arbeider på tvers av flere prosessorarkitekturer. Med ankomsten til Apples M1 ARM-baserte prosessorer vil kode skrevet i .NET for macOS kjøre som innfødte binære filer på både Intel- og ARM-basert maskinvare, slik at koden ikke trenger å gå gjennom et annet lag med emulering. Støtte for ARM64 vil tillate .NET 5-applikasjoner å kjøre naturlig på Windows på ARM-maskinvare, og dra nytte av funksjonene i Microsofts egne SQ1- og SQ2-prosessorer.
Noen scenarier, som Web Assembly og mobile operativsystemer, krever forhåndskompilert kode, og .NET 5 tilbyr en kompilator på forhånd sammen med JIT-verktøyet. AOT-kompilatoren er nå tilgjengelig for alle utviklingsmiljøer, og Uno Platform-teamet ser allerede betydelige hastighetsøkninger for sin Web Assembly-støtte, i størrelsesorden 7 til 15 ganger i forhold til den forrige Web Assembly-tolken.
Det er planer om å gjøre AOT-kompilatoren tilgjengelig som et alternativ for apper som trenger rask oppstart og lavere minnefotavtrykk, for eksempel på ressursbegrensede smartklokker og IoT-maskinvare. Et annet alternativ er distribusjon av enkeltfiler. Alt som trengs for et program (inkludert kjøretid) er samlet i en enkelt pakke, noe som gjør det lettere å distribuere .NET-applikasjoner i containere eller på ikke-Windows-systemer.
Den nye .NET skal ikke sees isolert. Ytterligere utvikling rundt Web Assembly med Blazor og plattform UI-utvikling med MAUI (multiplatform app UI), er også viktig. Ved å bruke en kombinasjon av disse teknologiene kan veldig lite målrettes mot .NET 5, fra Raspberry Pi-klasse maskinvare til Android-telefoner til Kubernetes-hostede containere som kjører på AWS og Azure.
Videre til .NET 6 i 2021
Et viktig poeng er at dette bare er ett skritt til i en prosess. .NET 5 er en nøkkelteknologi for separasjon av Windows APIer fra OS, Project Reunion-sammenslåing av WinRT og Win32 APIer, og flyttingen til både WinUI 3 og MAUI som UI-lag. Mye av dette arbeidet fortsetter med utgivelsen av .NET 6 i 2021 - målet for mange av disse prosjektene. Du trenger ikke å vente på at .NET 6 skal komme i gang med migrasjoner. Jo før du begynner, jo bedre, og gir deg tid til å håndtere eventuelle problemer som kan dukke opp.
Du bør se .NET 5 som et første skritt i neste etappe av. NET-reisen, en der du skal begynne å ta all den eldre koden og bestemme hva som er nødvendig å bringe frem ved å portere og oppdatere, og hva som må erstattes fullstendig. . Når 2020 slutter, planlegger du sannsynligvis utviklingsplanen for 2021. Med det i tankene bør .NET 5 være en linse som hjelper deg å fokusere på hva som må gjøres for å holde programvaren din klar for en mye raskere fremtid som ikke lenger er knyttet til Windows-utgivelser - eller til Windows i det hele tatt.
