Kompletní pohled na .NET 7

Update: Shrnutí Keynote z NET Conf 2022

 

Následuje originální text článku vydaný před zveřejněním .NET 7

1️⃣ Definice LTS aneb pro koho je .NET 7

Sudé verze .NETu Microsoft vydává jako tzv. LTS release. Ten má dlouhou podporu 3 roky od svého vydání. Vývojáři mají zajištěno, že .NET 6 bude podporován do listopadu 2024. V praxi to znamená, že Microsoft bude do tohoto data framework na měsíční bázi opravovat a vydávat bezpečnostní záplaty. Oproti tomu .NET 7 bude mít zkrácenou podporu na 18 měsíců Bude označován jako STS (Short Term Support). Zpravidla se počítá, že projekt běžící na .NET 7 po vydání verze .NET 8 do půl roka opět aktualizujete.

Verze	Druh release	Podpora
.NET 6	LTS	11/2024
.NET 7	STS	05/2024
.NET 8	LTS	11/2026

Stejná pravidla se týkají většiny souvisejících technologií, které Microsoft představí v rámci .NET Conf. Tento rok se bude konference konat 8. až 10. října a bude opět online a dostupná pro všechny vývojáře.

Pro upřesnění je vhodné dodat, že občas se některé technologie deklarují jiným přívlastkem. Například framework MAUI, který byl unifikován do .NET 6 není deklarován jako LTS. Důrazně varuji před používáním nových technologií, které doposud nikdy nebyly vydány v LTS režimu. Například v minulosti do této kategorie spadal Blazor WebAssembly. Technologie, která doposud nebyla vydána v LTS může do 18 měsíců upadnout v zapomnění. U produktů, které už v byly vydány v LTS režimu máme větší příslib jejich budoucnosti. Blazor WebAssembly už si tím prošel a dnes je deklarován v LTS režimu. Můžeme být klidnější.

2️⃣ Kdo by měl migrovat na .NET 7

Microsoft se snaží technologický stack vydávat jako celek, přestože se každá část tváří samostatně. Jinými slovy migrace se netýká jen .NETu jako takového, ale zahrnuje například:

• Runtime, Compiler
• Visual Studio
• C#
• Entity Framework Core
• webové frameworky (MVC, Razor Engine, Blazor)
• rozšíření frameworku

Migrací na .NET 7 se vývojářskému týmu otevřou nové verze všech výše uvedených technologií. Každá z nich občas přinese velmi užitečnou funkcionalitu. C# 11 bude možné používat jen s verzí .NET 7 a vyšší. Dle dokumentace:

EF Core 7 bude možné používat i na starším .NET 6.

Průběžná migrace na nové verze .NETu je výhodná z pohledu postupného vstřebávání novinek. Dva roky vyvíjet se zavřenýma očima před novými funkcemi a změnami může vést k složitějším migracím nebo ke špatným technologickým rozhodnutím. Například si vyberete místo EF Core jiný ORM nebo místo SQL Server jiný DBS v domnění, že nějakou funkcionalitu neumí. Ve firmách se často setkávám s tím, že vývojáři nové funkcionality neznají a při rozhodování volí zbytečně alternativní technologie.

Migrace na .NET 7 má i jednu nevýhodu. Zkracuje čas technické podpory a tudíž vás přinutí k aktualizaci na .NET 8 nejpozději v květnu 2024. V případě aplikací, které se stále vyvíjí to není žádný problém. Máte-li ale nasazené řešení, které si běží svým životem, migrace je v zásadě zbytečná. Můžete používat .NET 6 s podporou do listopadu 2024. Celý rok 2024 tedy budete mít na to, abyste migrovali na .NET 8. Verzi .NET 7 jednoduše přeskočíte, protože vám nic zásadního nepřinese. I když...

... záleží-li vám na výkonnosti, migrace na nové verze frameworku vám obvykle přinesou lepší performance. Přestože tedy projekt žije svým životem, migrace na .NET 7 nemusí být náročná a za své úsilí si aplikaci můžete nepatrně zrychlit. Například v EF Core 7 při vkládání záznamu do databáze nebude potřeba za určitých okolností transakce. Ušetříme 130 mikrosekund. Zdá se to jako malá hodnota, ale je to rozdíl 25 %. Když se podobných optimalizací sejde více, jejich intenzivní použití v kódu má v nakonec značný vliv i na výkon aplikace.

Stojí to za zvážení.

3️⃣ Jak náročná je migrace

Náročnost migrace záleží na technologicích, které používáte. V základu bude potřeba aktualizace csproj souborů. Dále pak záleží na mnoha okolnostech. Z mého průzkumu jsem se pokusil sestavit tabulku s očekávanou náročností migrace (zohledňuji zejména breaking changes) a množstvím novinek oproti verzi .NET 6 (latest major).

Technologie	Náročnost	Novinky
.NET (console, BCL)	★☆☆☆☆	★★☆☆☆
C#	★★☆☆☆	★★★☆☆
ASP.NET Core - MVC / REST API	★☆☆☆☆	★★☆☆☆
ASP.NET Core - Razor Pages	★☆☆☆☆	★★☆☆☆
Blazor Server	★★★☆☆	★★★☆☆
Blazor WebAssembly	★★★☆☆	★★★☆☆
gRPC	☆☆☆☆☆	★★☆☆☆
Minimal APIs	★★☆☆☆	★★★★☆
Entity Framework Core	★☆☆☆☆	★★★★☆

Vysvětlení:

• ☆☆☆☆☆ - bez práce / žádné změny
• ★☆☆☆☆ - okrajová breaking / nevýznamné novinky nebo vylepšení
• ★★☆☆☆ - jedna větší věc nebo více nepatrných drobností
• ★★★☆☆ - více novinek nebo změn, pravděpodobně se vás týkají
• ★★★★☆ - zásadní breaking / novinky, které nelze ignorovat
• ★★★★★ - revoluční změny, ze kterých nás bude bolet hlava a prsty

Dále popíšu obecně každou z nejčastěji používaných technologií a přidám odkazy na aktuální issues na githubu. S blížícím se releasem tyto seznamy nahradím přehledem vybraných důležitých novinek a změn.

.NET 7

Migrace z .NET 6 bude velmi jednoduchá, byť ne zcela bez práce. Změny a potenciální breaking changes jsou velmi okrajové a narazí na ně jen menší množství vývojářů. Za odměnu dostaneme především výkonnostní vylepšení.

C#

Jazyk C# 11 měl vždy velmi dobrou zpětnou kompatibilitu. Nová verze ale přináší několik vyhrazených slov, pravidel a uzamčení potenciálních problémových scénářů, na které pár vývojářů může narazit. Novinek bude tak akorát a zcela jistě narazíte na nějakou, kterou využijete. Pěkný přehled nabízí Language Feature Status

MVC a Razor Pages

MVC a Razor Pages spláchneme společně. Microsoft zde neinvestuje příliš mnoho úsilí a spíše přidává občas nějakou fíčurku k dobru. Aktuálně to nevypadá na zásadní změny. Je velmi pravděpodobné, že tu bude jedna věc, kterou někdo na projektech využijete. Například Output Cache nebo jedno z menších vylepšení.

• Localised number format and wrong input type for decimal fields #6566
• Add support for implicit inference of FromServices for DI types #39667
• Inferring FromBody.AllowEmptyBehavior based nullability #39754
• Consider adding support for TryParse as a way to bind primitives #39682
• EmptyBodyBehavior.Allow should allow a missing Content-Type #36466
• SkipStatusCodePagesAttribute should run before AuthorizeAttribute #10317
• ApiExplorer not handling multiple routes on same action method correctly #26234
• Inferring FromServices optionality based on nullability information #39757

Blazor Server & WebAssembly

Teoreticky migrace nemusí představovat žádné větší potíže. I když je tu poměrně mnoho novinek, Microsoft také od mnoha plánů upustil na úkor větve Blazor Hybrid.

• Expose location changing event for NavigationManger #14962
• Calling InvokeAsync(StateHasChanged) set default culture  #28521
• Empty Blazor project template #32832
• Productize the custom elements support package #38447
• Improve prerendering and authentication experience in Blazor #27592
• Design proposal: Bind get/set/after modifiers #39837
• Components don't reset their received parameters - hot reload #31272
• [Blazor][Wasm] Dynamic and extensible authentication requests #42580
• Better MSAL support for additional scenarios #38122
• Developers targeting browser-wasm can use Web Crypto APIs runtime#40074

gRPC

Tady se prakticky kromě podpory HTTP/3 již delší dobu nic neděje. Migrace nebude znamenat žádnou práci a zřejmě jedinou novinkou (a ne úplně přehlédnutelnou) bude JSON transcoding.

• [EPIC] gRPC JSON transcoding grpc/grpc-dotnet#1583 (gRPC/HTTP)

Minimal APIs

Zde bude mnoho konceptuelních vylepšení, které nebudou spadat vyloženě do breaking changes, ale zřejmě Vás přinutí do projektu sáhnout. Zároveň se dočkáme celkem velké porce drobných vylepšení na více frontách. Vypadá to, že právě Minimal APIs doznají v .NET 7 nejvíce změn. Plánujete-li psát nové API, dost možná budou Minimal APIs dobrá volba. Líbí se mi to čím dál více.

• Improve minimal api routing with grouping #36007
• Add support for endpoint filters #37853
• [Epic] OpenAPI in .NET 7 #37098
• Add antiforgery (anti-csrf) support to minimal endpoints #38630
• Support binding request body as Stream/ReadOnlySequence #38153
• Consider a nicer API for configuring JsonOptions #39226
• Make IResult methods more testable #37502
• Minimal APIs doesn't support binding to StringValues from query or headers #36726
• Minimal Actions - array support in method signatures from querystring binding #32516
• Usage of ProblemDetails is inconsistent throughout ASP.NET Core #32957
• [Epic]: Configuring minimal APIs for auth should be suitably simple & featured #34545
• Design validation for Minimal APIs #30666
• [Epic]: Analyzers for Minimal APIs + MVC #36637

Entity Framework Core

Oproti předchozím rokům bychom se mohli až na okrajové scénáře vyhnout breaking changes. Chystá se ale mnoho zajímavých novinek a je téměř jisté, že každý tým si z nich některou vybere. Zároveň je také dost možné, že některé nové fíčurky vývojáře donutí popřemýšlet nad designem databáze a provést drobné i větší změny. Na to už jsme ale u EF Core zvyklí.

• JSON Columns
• ExecuteUpdate and ExecuteDelete (Bulk updates)
• Faster SaveChanges
• Table-per-concrete-type (TPC) inheritance mapping
• Custom Reverse Engineering Templates
• Model building conventions
• Stored procedure mapping
• New and improved interceptors and events
• Query enhancements
• DbContext API and behavior enhancements
• Model building enhancements
• Improved value generation
• Migrations tooling improvements
• Performance enhancements for proxies
• First-class Windows Forms data binding

4️⃣ Technologický stack a migrace

Často dostávám i otázky související s přechodem mezi technologiemi. Obvykle se jedná o následující varianty:

Migrace z MVC na Razor Pages

V této oblasti nepřináší .NET 7 nic, co by některý z přístupů zvýhodňovalo. Stále platí, že pro vývoj nových webových aplikací s renderováním na serveru bych zvážil nejprve vhodnost Razor Pages a poté MVC. Z pohledu organizační struktury projektu mi přijde snazší ponechat použití MVC a pouze provést reorganizaci složek, controllerů a views. Já na většině svých projektů používám Razor Pages. MVC mám na administrace a prostředí s CRUD operacemi.

Migrace z MVC / RP na Blazor Server / WASM

V .NET 6 a .NET 7 už lze Blazor považovat za životaschopnou technologii a osobně mám méně zábran ji použít než v minulosti. Zde se spíše než o migraci dá mluvit o přepsání celého UI. To bude rozhodně snazší na projektech, kde je UI striktně oddělené od veškeré výkonné logiky aplikace. Přechod na Blazor WASM bude vždy o něco více či mnohem více komplikovanější než přechod na Blazor Server. Otázka k zodpovězení je, zda vám ta námaha přinese alespoň nějaké zásadní benefity.

Migrace z JS frameworku na Blazor WASM

Pokud se vám zcela nerozutekl JS tým vývojářů a nebo pokud se nepotíte u starých jQuery skriptů, nevidím v přechodu moc smysl. Vstup do světa Blazoru je běžný u vývojářů, kteří vytvářeli aplikace ve WinForms na .NET FW 4.x a nyní hledají alternativu v novém frameworku.

5️⃣ Technologie budoucnosti

Při pohledu na úsilí, které Microsoft vkládá do Blazoru už ze mě opadá prvotní strach z budoucnosti této technologie. Doposud jsem používal především Blazor Server, který mi přidává v projektech užitečnou funkcionalitu. V praxi mám například MVC aplikaci a její malou část mám řešenou pomocí Blazor Server. Týmům, které ještě nezačali stavět SPA aplikace v JS bych už doporučil zvážit Blazor WebAssembly jako alternativu k JS frameworkům. Microsoft i v .NET 7 věnoval Blazoru mnoho úsilí a vedle zmíněných modelů se dostává do popředí i Blazor Hybrid. Hosting model který umožňuje komponentám využívat schopnosti nativních zařízení (mobil, desktop) a který je podporován v .NET MAUI. Celkově se Blazor začíná "roztahovat" do všech směrů a začíná být velmi nepravděpodobné, že by ho Microsoft měl pohřbít. Blízká budoucnost tedy bude patřit především Blazoru a Minimal APIs.

Přestože se i v .NET 7 dočkáme nových funkcí, které použijeme v MVC a Razor Pages, lze pomalu ale jistě očekávat pozvolnou smrt MVC frameworku. Podobný trend vnímají i vývojáři na jiných platformách. Klíčová část MVC byla poslední roky používána pro vývoj REST API, nicméně poslední měsíce Microsoft dává jasně najevo, že to myslí vážně s Minimal APIs. Když pomineme hloupý a marketingově nezvládnutý název, mohou Minimal APIs během dvou let funkčně plně nahradit MVC. V .NET 8 už to bude pravděpodobně výchozí volba pro vývoj HTTP API. Nemyslím si, že by podpora MVC skončila podobně jako u WebForms, ale nových funkcí se dost možná dočkáme jen u Minimal APIs. Pokud se Microsoftu podaří držet nová API systematicky od dosavadní infrastruktury, mohl by zafungovat assembly linking a projekty postavené s Minimal APIs mají potenciál tvořit velmi minimalistický deploy balíček. To v kontexu odlivu firem do cloudu může být dobrý argument, proč se Minimal APIs stanou velmi rychle majoritní technologií pro vývoj HTTP API na platformě .NET.

6️⃣ Příprava na migraci a zdroje ke studiu

Průběžně sleduji přidávané funkcionality do frameworku na základě nich poskládám několik přednášek, webinářů a školení. Formu zvolím podle množství novinek a aktuálně to vypadá takto:

• Novinky v .NET 7 a C# 11 - bude ve formátu online veřejného a firemního školení
• Novinky v EF Core 7 - bude webinář a půldenní školení do firmy
• Novinky v Blazoru - vyberu ty nejzajímavější a udělám přednášku

7️⃣ Závěr

Přechod z .NET 6 na .NET 7 není nezbytně nutný a pokud si na něj nenajdete hned čas, nemusí vás to trápit. Já osobně zmigruji všechny projekty, do kterých průběžně sahám. Ty ostatní, co už mi někde rok leží bez zásahu ponechám na .NET 6. Výkonnost mě na nich netrápí a migrace by mi jen přidělala starosti. Na navštěvovanějších projektech se více zamyslím nad možnostmi redesignu některých částí aplikace, které nyní půjdou dělat elegantněji. Pro vývoj nových API budu zvažovat Minimal APIs jako první volbu.