Kompletní pohled na .NET 7

Miroslav Holec 1. srpna 2022 update 14. listopadu 2022

Článek se vztahuje k verzi produktu .NET 7

Tento článek byl napsán v roce 2022. Vývojářské technologie se neustále inovují a článek již nemusí popisovat aktuální stav technologie, ideální řešení a můj současný pohled na dané téma.

Microsoft již od vydání .NET 6 pracuje na další verzi .NETu. Příští major release se bude dle očekávání jmenovat .NET 7 a nebude spadat pod LTS. Znamená to, že ho můžeme ignorovat a nebo by nás měl zajímat? Odpověď je komplikovanější.

Pomáhám firmám s migrací .NET aplikací

Napište mi a domluvíme se. Pomáhám firmám v Česku a na Slovensku migrovat aplikace z různých verzí .NET Frameworku na nejnovější vydání.

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í.

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.

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.

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í.

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

.NET Conf Keynote Watch Party

Přijďte na společné sledování .NET Conf Keynote, zahájení online konference, která každoročně uvádí novou verzi .NET. Společně si live promítneme keynote (17:00-18:00), následovat může panelová diskuze s experty na .NET. Zamluvený máme sál Morava, můžeme pak pokračovat do některého z blízkých restauračních zařízení. Neseďte doma, přijďte pokecat!

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.