.NET 5 – czy Microsoft buduje krętą drogę do sukcesu?

Konferencja Build 2019 to jedna z najważniejszych imprez spod znaku .NET. To właśnie tutaj pokazywane są najważniejsze nowości i plany na przyszłość związane z technologiami od giganta z Redmond. Nie inaczej było w tym roku. Zostały przedstawione zmiany powiązane z Azurem, DevOpsem, AI, a nawet film pokazujący nową konsolę systemową. Jednakże jednym z bardziej kluczowych momentów było zaprezentowanie nowej platformy programistycznej - .NET 5.

Programiści technologii .NET nie mają łatwego życia od roku 2016. To wówczas wypuszczono pierwsze wydanie .NET Core - nowego frameworku od Microsoftu, który to podczas premiery mocno namieszał w dość zamkniętym świecie .Net. Sam Core był wyjątkowy, pozwalał na pisanie multiplatformowych aplikacji. Kod w .NET mógł zatem powstawać i być uruchamiany na systemie Windows, a także Linux czy mac OS. Sama platforma stała się także znacznie lżejsza, co automatycznie zwiększyło wydajność tworzonych aplikacji, a źródła .NET Core trafiły na GitHuba.

Zalety niosły ze sobą wyrzeczenia. .NET Core nie był w linii prostej kompatybilny z klasycznym .NET Frameworkiem. Tworzenie aplikacji w nowym frameworku wymagało stworzenia projektu na nowo. Oczywiście czysty kod napisany w C# można było spokojnie przenieść do Core, ale specyficznie biblioteki musiały być zgodne z .NET Core lub chociażby z .NET Standardem.

W roku wydania .NET Core 1.0 wielu deweloperów pod wpływem znanej i bardzo popularnej metodyki Hype Driven Development (czyli śmieszkowa nazwa na rzucanie się na wszystko co nowe) zaczęło portować istniejące projekty (lub tworzyć nowe) na świeżą platformę programistyczną od Microsoftu. Niestety okazało się to sporym błędem.

Wydana ponad rok później wersja 2.0 niosła ze sobą bardzo wiele nowości i usprawnień, ale kosztem kompatybilności wstecznej. Duża ilość newralgicznych zmian w samym .NET Core powodowała, że podbicie wersji z gałęzi 1.x do nowej 2.x było miejscami olbrzymim wyzwaniem. To przez chwilę ostudziło pęd ku nowej platformie, ale tylko na chwilę.

.NET Core stawał się jednak coraz bardziej przyjazny i dopracowany. Gałąź 2.x rozwijała się stabilnie i bez już większych niespodzianek. Kolejne wersje przynosiły nowe usprawnienia i ficzery, a także przenosiły bazowe rozwiązania ze starego .NET Frameworka na .NET Core. Przy okazji multiplatformowej modzie w Microsofcie zyskaliśmy bardzo dobre narzędzia. Visual Studio Code stał się niezmiernie ciekawym i lekkim edytorem (lub jak kto woli IDE) na wiele systemów. Nie konkuruje on z Visual Studio na Windowsa, ale jest ciekawym multiplatformowym narzędziem dla programistów. Z tej okazji zyskali również posiadacze systemu z jabłuszkiem, gdyż Visual Studio na mac OS (czyli Xamarin Studio po rebrandingu, które było rozwinięciem MonoDevelop) otrzymało wiele potrzebnej troski od Microsoftu i stało się dość potężnym IDE.

Na wrzesień tego roku zaplanowano prezentację nowej wersji .NET Core z linii 3.x. Ewidentnie ta gałąź będzie skupiała się na stabilizacji i próbie dogonienia w kwestii przenoszenia rozwiązań z klasycznego .NET Frameworku. Zatem można będzie pisać w Core 3.0 aplikacje desktopowe z wykorzystaniem WPF i Windows Forms. Wynikowe pliki mają być mniejsze, a aplikacje znacznie lżejsze w czasie działania. Pozwoli to na przeniesienie kolejnych projektów ze starego frameworka na nowego Cora. Uzyskamy również możliwość wykorzystania nowej wersji języka C# w wydaniu 8.0.

Niestety tutaj następuje lekki zgrzyt (niejedyny, o czym dalej), który swego czasu mocno podzielił środowisko .NET podczas pierwszych planów co do Core 3. Otóż nowa wersja oznaczone numerkiem 3.0 będzie miała wsparcie dla tworzenia aplikacji desktopowych tylko na Windowsa. Pytaniem jest zatem jak można traktować multiplatformowość .NET Core skoro część frameworku będzie dostępna jedynie na system z okienkami.

Kolejnym nieoczekiwanym dodatkiem (a raczej brakiem) w .NET Core 3.0 będzie zatrzymanie dalszego przenoszenia rozwiązań znanych z .NET Framework. Do tej pory kolejne wydania Core przynosiły porty technologii znanych z klasycznego .NET. W tym momencie jawnie zostało ogłoszone, iż zarówno Web Forms, jak i WCF, nie będą portowane do nowego Cora. Wiąże się to z tym, iż osoby piszące w któreś z tych technologii nie będą mogły przejść z kodem na .NET Core. O ile jeszcze w przypadku Web Forms jest to zrozumiałe, gdyż samo rozwiązanie jest mocno archaiczne, a utrzymywanie takich systemów jest wyzwaniem godnym najwyższych odznaczeń. Problemem jest jednak WCF, który nie jest przestarzały, a jego duża elastyczność sprawia, że nadal jest wykorzystywany w wielu firmach jako chociażby zewnętrzne API do komunikacji. Widać to było szczególnie w komentarzach na oficjalnym blogu Microsoftu, gdzie ogłoszono plany odnośnie .NET Core 3.

Microsoft w przypadku Web Formsów zaleca przesiadkę na Blazora. Jest to niby duchowy spadkobierca Web Formsów, oparty na WebAssembly, jednakże mam wrażenie, że nie jest to jeszcze kod, który można użyć na produkcji. W przypadku WCF alternatywą jest Web API. Wygląda na to, że nie wszyscy będą mogli w miarę bezboleśnie przejść na nowego Cora, aczkolwiek i tu jeszcze nie jest wszystko jasne, o czym za chwilę…

Jeśli ktoś po przeczytaniu czym jest .NET Core i jakie niesie zmiany, dostał bólu głowy, to teraz proszony jest o wzięcie tabletek przeciwbólowych, najlepiej dwóch ;) Pod koniec roku 2020 Microsoft zamierza wydać nowe dziecko związane z platformą programistyczną i będzie to .NET 5 (pominięto w numerowaniu 4, aby nikt nie czuł się zagubiony, jednakże powoli już zaczyna się robić całkiem sporo tych wersji .NET).

Ma być to połączone najlepszych rozwiązań znanych z .NET Core, .NET Framework, Xamarina i Mono (a założyłbym się, że jakiś czas temu to .NET Core miał to wszystko posiadać, ok koniec złośliwości). Ważnym założeniem są tu środowiska uruchomieniowe. .NET 5 posiadać będzie CoreCLR (z .NET Core) i Mono (a jakże, z Mono), gdzie kod będzie mógł przełączać się z jednego środowiska uruchomieniowego na drugie.

Samo Mono ma być używane chociażby do programowania pod iOS i Blazora, gdyż zarówno kod pisany na smartfony od Apple i Web Assembly wymagają kompilacji AOT (ahead-of-time). AOT w obu tych rozwiązanych jest mocno związane z Mono i to właśnie na tym środowisku będą one odpalane. Pamiętajmy jednak, ze również.NET Native jest kompilacją AOT, ale tylko w przypadku Windowsowego UWP.

.NET 5 obiecuje także skupienie się na niezawodności i szybkości CoreCLR oraz redukcji rozmiarów Mono AOT. Zatem połączenie tych środowisk wygląda na chęć rozszerzenia multiplatformowych możliwości .NET na jeszcze większą ilość urządzeń, przy jak najmniejszej ilości frameworków i różnych rozwiązań systemowych. Połączenie Mono i .NET Core to znak, iż Microsoft ma zamiar na stworzenie jednego uniwersalnego pełnego środowiska developerskiego skierowanego na różne urządzenia docelowe.

Nowy .NET 5 i jego przyległe technologie są jeszcze w fazie tworzenia koncepcyjnego. W momencie promowania .NET Core podkreślana była często duża rola .NET Standard. Można określić to jako zbiór bazowych interfejsów, jakie muszą być zaimplementowane przez wszystkie implementacje .NET (Core, Classic .NET, Mono, Xamarin). W momencie prezentacji .NET 5 jego istnienie już nie jest takie oczywiste, skoro .NET 5 zbiera wszystkie technologie pod jednymi skrzydłami. Microsoft sam jeszcze do końca nie wie jaką rolę odegra .NET Standard w .NET 5. Czas pokaże.

Microsoft jasno daje do zrozumienie, że przyszłością obecnie jest .NET Core. Nowe projekty już warto tworzyć w Corze. Z drugiej strony w niedalekiej aż tak bardzo przyszłości .NET Core dostanie aktualizację do .NET 5. Będzie to zatem ewolucja, a nie rewolucja jaka miała miejsce w przypadku przejścia z klasycznego .NET do wersji Core. Oczywiście szczegóły zapewne będziemy poznawać przez najbliższe miesiąca (oby nie lata).

Sam rozwój .NET Framework zostanie zatrzymany na wersji 4.8, ale z aktualizacjami bezpieczeństwa i tymi pod kątem wydajności. Zatem już można oficjalnie odtrąbić, iż .NET Framework został już odstawiony na boczny tor, a przyszłością jest .NET Core.

Będąc w tym wątku warto dodać o brakach .NET Core 3. WCF oraz Web Forms w tym momencie zatrzymują się w kwestii rozwoju (aczkolwiek ten ostatni to już chyba od dawna stał w miejscu), aczkolwiek… chyba nie do końca? Microsoft nie zamierza przenosić tych rozwiązań do .NET Core i .NET 5. Zatem zostaną one w najbliższym czasie zapomnianą technologią w klasycznym .NET, tylko czy aby na pewno? WCF i Web Formsy zostały przeniesione przecież… na Mono, więc może będzie jeszcze jakaś luka, aby móc chociaż na multiplatformowym i uniwersalnym .NET 5 postawić w ramach kompatybilności wstecznej, którąś ze starszych technologii. Kolejne pytania bez odpowiedzi.

Podsumowanie może być tylko jedno – .NET (jako grupa technologii) rozwija się bardzo dynamicznie w ostatnich latach, a Microsoft wcale nie zwalnia tempa. Stopniowe wygaszanie .NET Frameworka już jest faktem. Nowy Core szykowany był powoli jako główny bazowy framework do prac deweloperskich. Microsoft nie zrobił tego w jednym, krótkim przedziale czasowym, ale rozłożył to na lata i strategia ewidentnie poskutkowała. Deweloperzy mieli czas na zaznajomienie się z nowym Corem, jednocześnie próbując migrować obecne rozwiązania na nowe.

Nowy .NET 5 jest już bardziej tajemniczym projektem. Pomimo jasnych założeń co do multiplatformowości pod jednymi skrzydłami, jest tu jeszcze wiele szczegółów, o których nawet sam Microsoft nie do końca wie w jakim kierunku będą rozwijane (lub zostaną zastopowane). Na plus trzeba potraktować to, iż .NET Core został otwarty, jak i inne „sąsiednie” projekty (np. Entity Framework Core) . Jest to o tyle zaskakujące, że w momencie kiedy Microsoft otwiera się z kodem do deweloperów, Oracle w tym samym czasie niszczy Java EE. Co więcej, Eclipse Foundation jest zmuszane do używania tylko jednej wersji środowiska uruchomieniowego od Oracle, zatem Eclipse Foundation nie będzie już neutralnym bytem, co może spowodować cofnięcie ulg podatkowych, a finalnie nawet zamknięcie projektu. Miejmy nadzieję, że tak się jednak nie stanie i dalej .NET i Java będą mogły bezproblemowo konkurować na polu najlepszych języków dla deweloperów. W tym wyścigu Microsoft zyskał znaczną przewagę i raczej nic nie wskazuje na to aby oddał palmę pierwszeństwa konkurencji.