Migrace na .NET 5 a .NET 6

Na jakou verzi .NETu migrovat?

Jednoduchá odpověď zní migrujte na .NET 5. V zásadě jde o to, že vývojáři dnes používají verze 2.1 až 5.0. Ve verzích frameworku 2.1 až 3.1 došlo k mnoha změnám včetně zpětně nekompatibilních změn. To se týká Entity Framework Core i samotného webového frameworku. Dá se říci, že nejtěžší je migrace směrem na verzi 3.1. Mezi verzemi 3.1 a 5.0 jsou změny minimální a proto se vyplatí sfouknout to všechno najednou. Verze .NET 5 má podporu až do února 2022, takže lze podzim a zimu využití právě pro migraci na tuto verzi. Přepnutí z .NET 5 na .NET 6 bude v podstatě jen formalita a lze ji udělat dodatečně třeba zkraje příštího roku.

Není lepší rovnou migrovat na .NET 6?

Nová verze .NET 6 vyjde až v listopadu. Přijde mi zbytečné čekat, když do února 2022 lze bezpečně používat produkčně ověřenou verzi .NET 5. S masivním nasazováním .NET 6 se objeví různé drobné chyby, které odladí patche v prosinci a v lednu. Nebude to asi nic zásadního, ale pokud má někdo dnes čas, proč ho nevyužít k migraci už teď.

Zvládneme migraci bez cizí pomoci?

Microsoft vydává různé migrační průvodce, takže odpověď zní ano. Bude to stát mnoho času, protože průvodce migrací je vždy rozsáhlý a tým v praxi nemá čas vše procházet. Nakonec tak deleguje tuto práci na jednu osobu, která projekt nějak zmigruje. Zbytek týmu nemá obvykle o změnách moc ponětí a netuší, co se v projektu změnilo. Proto doporučuji absolvovat mé školení, kde všechny zásadní funkce vysvětluji.

Migrace z .NET Core 3.1 na .NET 5.0 je triviální

To jsem si myslel také a v zásadě je to pravda. Mezi .NET Core 3.1 a .NET 5.0 nejsou navzdory názvu žádné velké změny. Tou revoluční verzí byla trojka, zbytek je už jen jako trocha usedlého prachu. Potíž je v tom, že vývojáři často ani netuší, co se změnilo v minulosti mezi verzemi 2.x a 3.x. O migraci se postaral jeden člen týmu a ostatní vývojáři nyní netuší, k čemu je endpoint routing, generic host nebo se diví, že jim nefungují správně cookies. Školení migrace je zároveň revizí projektu a příležitostí zpětně pochopit vlastní projektové nastavení. Z mnoha projektů už umím prapodivné kusy kódu vysledovat.

K čemu je tedy školení?

V rámci školení jsem schopen celému týmu vývojářů ukázat klíčové novinky a změny v .NETu. Školení mám vytvořené na míru pro každý tým, takže ukážu jen funkce, které jsou pro týmový projekt relevantní. Tým mi obvykle proti NDA poskytne kód, který projdu na základě mého checklistu. Součástí školení je projekt postavený na staré verzi a následné demo jeho migrace včetně vysvětlení všech podstatných funkcí. Tým dostane na konci školení dvě verze projektu (před a po) včetně prezentace s přehledem novinek.

Nebylo by lepší migrovat přímo náš projekt naživo?

Školení pracuje s malý projektem, do kterého lze snadno cokoliv zapojit, rychle ho zkompilovat a nerozptyluje od jádra věci. Když bude v reálném projektu například špatně nastavená serializace, rozsype se kód na mnoha místech a valná část školení bude jen o přepisování toho samého na X místech. Školení mám vymyšlené tak, abych v jednom příkladu ukázal více souvislostí a funkcí, které dobře fungují. Klíčové je, že si demo připravuji podle školeného týmu. Máte-li v projektu něco specifického (třeba DI nebo jiné logování), pokusím se to připravit i do demíčka.

Co když nemůžeme kód sdílet?

Je více možností. Pokud není cestou NDA, lze mi poslat několik CS tříd na základě mého seznamu. V těchto třídách zaručeně není žádné tajemství a můžete je zredukovat. Není-li možné ani toto, spojíme se přes Zoom a doptám se na to, co potřebuji vědět. Nejlepší je samozřejmě kód nasdílený, protože mohu upozornit i na další věci, kterých si všimnu.

Jak je to s novinkami v C#?

Jazyk C# se za poslední roky příliš nezměnil. Přibylo v něm sice pár stovek nových funkcí, ale většina z nich je naprosto zbytečná. Zavádění různých syntaktických vychytávek projekty často znepřehledňuje, protože málokterý tým kompletně novinky ovládá. Přesto se v C# objevilo pár důležitých funkcí, které mají reálný vliv na vývoj. V rámci školení migrace tento velmi úzký výběr funkcionalit ukazuji právě v souvislosti s novinkami ve frameworku. Příkladem je nový typ record, rozhraní IAsyncEnumerable nebo funkcionalita Nullable Reference Types. To jsou ukázky velkých novinek, které mají reálný dopad na vývoj aplikací. Pattern matching nebo switch výrazy jsou proti tomu nicotné.

V jakém stavu jsou projekty jiných týmů?

Samotné projekty z hlediska použití frameworku jsou spíše v dobrém stavu. Některé projekty už v minulostí prošly nucenou migrací. V praxi vývojář prošel manuál od Microsoftu a upravil řádky kódu tak, jak mu bylo doporučeno až do fáze, kdy je projekt spustitelný. Často ale chybí pochopení provedených změn. To má za následek, že:

• vývojáři píšou něco, co už framework dávno umí
• vývojáři mají nastaveno něco, co jim překáží
• vývojáři nezapojili něco důležitého, bez čeho projekt na první pohled správně funguje
• vývojáři hledají půl dne chybu v něčem, co fungovalo a nyní se to chová jinak

Jaké jsou časté nedostatky projektů po migraci?

Na API projektech je neskutečný binec v serializaci. Microsoft představil nový serializer a vývojáři ho míchají všemožně se starším Newtonsoftem. V souvislosti s API vývojáři často nesprávně používají například HttpClient. Úplně ideální není také štábní kultura v controllerech. Chybí atributy, nevyužívají se nové chybové struktury nebo anotace pro přesnější generování Open API Specifikace.

Setkal jsem se se špatným pořadím middlewarů po zavedení endpoint routingu. Ten má velký potenciál, který vývojáři často neumí využít. Mnoho vývojářů používá různé konzolovky s prapodivně nastavenou dependency injection, přitom řešením je už 2 roky Generic Host. Potíže jsou i na tradičních webových projektech. Na jednom projektu se vývojáři trápili neustálou rekompilací místo toho, aby si zapojili NuGet balíček, který podporuje kompilaci views při obnovení okna prohlížeče.

Revize projektu není jen o mezigeneračních změnách ve frameworku. Často objevím i jiné související potíže. Například důvtipné obcházení logování, kterým se tým připravuje o logy z tříd napsaných vývojáři z Microsoftu.

Jaké změny jsou v EF Core?

Obrovské. Tady udělal Microsoft velký kus práce, který se bohužel neobešel bez breaking changes. V EF Core je mnoho změn i mnoho drobných užitečných novinek. V rámci školení je prostor ukázat jen zlomek z nich, které vývojáři v praxi reálně použijí. Některé dříve navržené modely budou fungovat i po migraci. Neznamená to ale, že by nevznikl nový prostor na vylepšení. I tady navíc často narážím na code smell, který lze elegantně odstranit. Výjimkou nejsou DbContexty dlouhé 2000 řádků.

V čem bude revoluční .NET 6

Vlastně vůbec v ničem. Microsoft sice o .NET 5 a .NET 6 mluví v superlativech, ale pro běžné vývojáře se jedná jen o malé záplaty revoluční verze 3.x. Ta přinesla nové druhy projektů a principy jako generic host, endpoint routing a další. Změny v posledních verzích jsou především pod pokličkou. Pro .NET 6 bude důležité, že bude dodána s vývojářskou podporou do listopadu 2024. To už je slušná doba. Více jsem napsal o .NET 6 v článku Velkolepý příchod .NET 6.

Kolik času zabere samotná migrace?

Školení je zpravidla půldenní. U konečné migrace je to různé. Záleží na verzích, mezi kterými se migruje, počtu funkcí v aplikaci i její rozsahu. Vývojáři většinou mnoho času tráví u EF Core nebo při snaze srovnat chování serializerů. Menší projekty bez EF Core se obvykle dají aktualizovat "do oběda", tedy během krátkého dopoledne.