Včera byla na přednáškách v rámci konference Build poodhalena budoucnost .NET platformy. Asi nejzajímavějším oznámením byla roadmapa pro .NET Core 3.0, která má zahrnovat i podporu Windows Forms a WPF. To může způsobit určité zmatky a pochybnosti ohledně budoucnosti .NET Frameworku samotného. Jako MVP a RD jsme měli i několik setkání s lidmi z produktových týmů a diskutovali s nimi, jak si budoucnost .NETu představují, takže se pokusím to objasnit.
Pro UWP zatím ještě nenadešel správný čas
Universal Windows Platform měla být hlavní technologie pro vývoj desktopových (a původně i mobilních) aplikací pro Windows. Tato technologie nabízí spoustu zajímavých funkcí, které ve WPF nebo WinForms nenajdeme – silně typový data-binding pomocí xBind, pořádnou podporu pro dotykové displeje, komponenty pro responsivní layouty a mnoho dalšího. I pokud se podíváte na funkčnost těch nejzákladnějších komponent, jako třeba TextBox, zjistíte, že TextBox v UWP toho umí nejvíc – kontrolu pravopisu, automatické zobrazení dotykové klávesnice ve chvíli, kdy na TextBox ťuknete prstem, podporu psaní perem atd. Je tam mnoho nového API pro přístup k novějším částem a funkcím Windows.
Zásadním problémem UWP je ovšem to, že funguje pouze na Windows 10, což je sice nejrychleji adoptovaná verze Windows v historii, ale stále je mnoho počítačů, zejména ve firemním prostředí, které běží typicky na Windows 7. Backportovat UWP ne o jednu, ale o dvě verze Windows nazpátek, by určitě bylo extrémně obtížné, takže Microsoftu (a tedy i nám) nezbývá než čekat, než starší Windows postupně vymřou.
Windows 10 už (podle oznámení na keynote) běží na více než 200 milionech počítačů ve firmách, nicméně bude trvat několik let trvat, než bude UWP obecně použitelné, a to zejména v segmentu business aplikací. Proto bude potřeba Windows Forms a WPF ještě podporovat, a ne jenom pár let – jak ve Windows Forms, tak ve WPF dnes stále vznikají nové projekty a počet uživatelů těchto technologií každý rok roste.
Některé chyby .NET Frameworku nejde opravit kvůli kompatibilitě
.NET Framework se vždy snažil o maximální zpětnou kompatibilitu, což je ve firemním prostředí v podstatě nutnost. Každá verze sice přináší drobné breaking changes, většinou mají ale minimální impact a pocítí je naprosto minimální množství firem či uživatelů. Zachovávání zpětné kompatibility ovšem znemožňuje opravit určité chyby či nedostatky v návrhu, jako třeba nepodpora nestandardních DPI ve Windows Forms.
Microsoft zkrátka nemůže vydat novou verzi .NET Frameworku, kde by DPI ve Windows Forms fungovalo správně – rozbil by tím všechny .NET aplikace na počítači, na který by se tato nová verze .NETu nainstalovala. .NET Framework totiž nemůže běžet side by side ve více verzích. Spousta aplikací se s nepodporou jiných DPI navíc vypořádala sama a velikosti prvků si dopočítává za běhu pomocí kódu, což by se v případě opravy .NET Framework rozbilo také.
.NET Framework rozhodně není mrtvý (byla oznámena budoucí verze 4.8) a Microsoft jej bude dále udržovat. Jedná se o integrální součást Windows a nemálo komponent ve Windows na .NET Frameworku závisí – bez něj by Windows nefungovaly.
Dokud tu tedy budou Windows, bude tu i .NET Framework. Díky .NET Standard na něm budou fungovat všechny nové knihovny, které se v .NET světě vyvíjejí, včetně nových platforem ASP.NET Core, Entity Framework Core apod. Pokud používáte .NET Framework, nebudete tedy ochuzeni ani o tyto nové technologie.
A samozřejmě bude .NET Framework dostávat bugfixy a některá nová API - nedávno byla například přidána podpora pro cesty delší než 260 znaků nebo dependency injection pro ASP.NET Web Forms. Ovšem náklady na údržbu a rozšiřování .NET Frameworku jsou pro Microsoft vysoké, takže ve frameworku samotném (ne v knihovnách okolo) se dá pravděpodobně čekat jen mírná evoluce v mezích zákona.
.NET Core 3.0
.NET Core je multiplatformní verze .NETu, jejíž první verze byla uvedena před 2 lety. Aplikace kompilované proti .NET Core mohou běžet jak na Windows, tak na Linuxu nebo Mac OS.
.NET Core může být nainstalován ve více verzích side by side, a dokonce podporuje i self contained scénář – aplikace si nese runtime s sebou a nevyžaduje, aby byl na daném zařízen nainstalován. To zásadně přispívá ke zpětné kompatibilitě – pokud je aplikace pro firmu kritická, může si runtime nést s sebou a neovlivní ji to, že někdo nainstaluje novější verzi runtime.
.NET Core umožňuje na Windows referencovat i knihovny kompilované proti .NET Frameworku. Díky type redirectům v knihovně netstandard.dll budou tyto knihovny fungovat i v procesech běžících na .NET Core runtime. Zjednodušeně to funguje tak, že System.Object, který je v .NET Frameworku obsažen v assembly mscorlib.dll, se přesměruje na System.Object, který je v assembly System.Private.CorLib, která je součástí .NET Core.
Smysl to samozřejmě má jen na Windows – knihovny .NET Frameworku typicky volají různá Windows API nebo wrappují COM objekty, což na Linuxu nebo Mac OS fungovat nebude.
Ten samý princip bude využit i u Windows Forms a WPF. To, že je bude možné používat z .NET Core, neznamená, že by tyto technologie fungovaly na Linuxu a Mac OS. Jen díky tomu získají pár výhod, které .NET Core přináší.
Zároveň je to pro Microsoft příležitost, jak vyřešit různé palčivé problémy, například to nešťastné DPI. Nebude tedy pravděpodobně zachována stoprocentní zpětná kompatibilita mezi WinForms na .NET Core a .NET Frameworku, na druhou stranu při portování určitě nebude tak složité dostat UI do funkčního stavu, a díky výhodám plynoucím z toho, že aplikace poběží na .NET Core, se portace velmi pravděpodobně vyplatí.
Možná se ani nebavíme o tak vzdálené budoucnosti - na Buildu včera ukazoval Scott Hunter a Scott Hanselman demo, v němž měli WinForms aplikaci využívající Telerik komponenty, a rozběhli ji pod .NET Core 2.1. Fungovala úplně stejně a dokonce v ní některé operace byly rychlejší díky optimalizacím v runtime .NET Core. Dokonce se jim pomocí linkeru podařilo aplikaci zabalit do jednoho 60MB velkého EXE souboru a spustit ho na počítači, kde nebyl nainstalovaný .NET Core vůbec.
Co dál?
Pokud máte stávající Windows Forms nebo WPF aplikace, jsou v podstatě dvě možnosti:
- Nechat aplikaci na .NET Frameworku. Tato možnost se hodí v případě, že do aplikace nechcete moc zasahovat a potřebujete, aby fungovala, nebo pokud se jedná o kritický nástroj, který se sice dál vyvíjí, ale u kterého nechcete riskovat breaking changes. .NET Framework nikam nejde a bude tu stejně dlouho jako Windows.
- Přeportovat aplikaci na .NET Core. Pokud hodláte aplikaci dále vyvíjet a chcete přeskočit na modernější platformu, .NET Core 3.0 se zdá jako správná doba k přechodu na .NET Core. Většina API z .NET Frameworku je již součástí .NET Standardu, zbytek vcelku kompletně dolepily různé komunitní knihovny. Aplikace nezíská multiplatformnost, ale výhodou bude například vyšší rychlost (.NET Core má obrovské množství optimalizací, které v .NET Frameworku nebylo možné udělat), nebo o mnoho rychlejší kompilace.
Pokud vás toto téma zajímá, přijďte se 28. – 30. května 2018 podívat na konferenci Update Days: Legacy App. Uvidíte spoustu nápadů na věci, které můžete na stávajících projektech snadno provést, abyste si usnadnili život, a zároveň si budete moci popovídat se speakery o tom, co vás na vašich projektech trápí.
A co webové aplikace?
Současně s ASP.NET Core 2.1 RC, které obsahuje pár novinek, Microsoft spustil i službu Azure SignalR, která řeší problémy v SignalR aplikacích (hodí se zvláště pokud máte tisíce nebo desítky tisíc klientů – služba to flexibilně škáluje za vás).
Velké pozornosti se pochopitelně těší i Blazor, nicméně u něj ještě není jisté, jestli se z něj vyvine reálný produkt a Microsoft o něm mluví jen velmi opatrně. Myšlenka psát webové aplikace bez JavaScriptu, čistě v C#, je skvělá, a s DotVVM se nám to podařilo už před 2 lety. Web Assembly umožňuje spouštět C# kód přímo na klientovi (což je jiný princip, než využívá DotVVM), ovšem pořád je tam mnoho technických problémů, například s garbage collection, nebo aktuálním problémem v Safari, kde Apple opravou jedné bezpečností chyby Web Assembly v Safari rozbil a neví se, kdy to bude opraveno.
Je otázkou, jak to dopadne, jak velké budou aplikace psané tímto způsobem (protože prohlížeč si aktuálně musí stáhnout všechny DLL knihovny), jestli a kdy k tomu budou dostupné komponenty třetích stran a zdali budou nějaké rozumnější možnosti komunikace Blazorové aplikace se serverem než pomocí RESTu a Swaggeru, který má spoustu omezení a nevýhod (například neumí generické typy). Zatím se k tomu Microsoft staví jako k experimentu a myslím, že trochu panuje obava, aby tato technologie nebyla další Silverlight.
Přirozeně mě napadlo, jestli není v plánu na .NET Core 3.0 naportovat i System.Web, a ptal jsem se na to pár lidí, nicméně tam by to bylo zřejmě mnohem složitější kvůli vazbám na IIS nebo Global Assembly Cache (ASP.NET si předkompilovává stránky samo). Zatím se nic takového neplánuje, takže ASP.NET Web Forms to s přechodem na .NET Core nebudou mít tak lehké. Opět se zde nabízí cesta využít DotVVM, které se dá hostovat ve stejné aplikaci, a postupně překlápět jednotlivé stránky, až celá Web Forms část zmizí a aplikace tak půjde přepnout na .NET Core.
To jsou samozřejmě jen některé novinky z konference Build. Hodně oznámení se týkalo umělé inteligence, cloudových služeb a Microsoft Graph API. To nejzajímavější najdete na Twitter účtu @dotnetcollege.