Czy .NET 5 powinien być zintegrowany z Windows?

.NET Framework jest zintegrowany z Windowsem od wersji 3.0, którą opracowano na potrzeby systemu Windows Vista. Poprzednie wersje często były jednak instalowane na Windows XP, gdzie stanowiły wymaganie wstępne dla jakiegoś oprogramowania lub wręcz pchał je automatycznie Windows Update. Powodem integrowania Frameworku z systemem nie była "promocja", trudno bowiem promować środowisko uruchomieniowe na konsumenckim systemie (jaki miałoby to dać efekt?). Obecność .NET FX miała poszerzyć możliwości programowania na platformie Windows. Poza pisaniem aplikacji Win32 możliwe stało się uruchamianie programów w "nowoczesnym" języku, i to bez potrzeby doinstalowywania np. Javy.

Olbrzymi, jak na owe czasy, rozmiar .NET sprawiał, że docelowo aplikacja mogła ważyć tylko kilkaset kilobajtów. Nie trzeba było dodatkowo pobierać pięciusetkrotnie większego środowiska, tylko po to, żeby ją uruchomić. Przewagi tej nie miała Java. Dlatego .NET Framework stał się elementem systemu i był widoczny globalnie: nikt nie musiał dostarczać własnej kopii ani doinstalowywać nic do już obecnej.

Przeciwnicy integrowania .NET Framework często posługują się argumentami, które tylko brzmią rozsądnie, ale w praktyce są pozbawione treści. Mówiąc, że .NET "nie jest potrzebny" lub "Microsoft znowu coś kombinuje" ("znowu" trwa od piętnastu lat) nie dostarcza się tak naprawdę wytłumaczenia, dlaczego miałoby go w systemie nie być. Podobnie chybione są sugestie, że "nie należy go używać". Niezależnie od tego, czy są trafne czy nie, są jedynie pozornym argumentem, w praktyce stanowiąc jedynie opinię rymującą się z tematem. Oszczędzenie dwustu megabajtów na systemie ważącym sto razy więcej także nie jest zbyt przekonujące. I tak dalej.

Wobec tego być może należy dodać do Windows 10 środowisko .NET 5? Microsoft Edge jest na przykład serwisowany oddzielnie i aktualizuje się częściej niż w ramach dorocznego dostarczania nowej wersji Dziesiątki. Nie ma technicznych przeszkód, by .NET nie mógł zachowywać się tak samo. Są rzecz jasna wady takiego podejścia, ale wady to nie przeszkody. Jeżeli równoważą je zalety – być może .NET 5 byłby dobrym dodatkiem do systemu?

Podobnie, jak Linuksy domyślnie wyposażone w interpretery Perla i Pythona umożliwiają użytkownikowi tworzenie własnych programów przez konieczności pobierania specjalnych narzędzi, Windows zezwalałby na to samo, integrując PowerShella i .NET. W obu przypadkach jest to oczywiście pewne nadużycie, bo programowanie bez zasobów PIP, CPAN i NuGet bywa nieznośne, ale tak zaopatrzone systemy są bardziej wszechstronne niż te, które tego typu narzędzi nie posiadają.

Niemniej, "czasy się zmieniają" i integrowanie .NET 5 z Windows 10 to dziś zły pomysł. Korzyści, jakie czerpano z obecności frameworków w systemie, nie są już dziś tak widoczne (lub sensowne) jak 10-15 lat temu. Co więcej, poleganie na zewnętrznych zależnościach okazało się przynosić bardzo wiele szkody. Aby zrozumieć potencjalne problemy, jakie wywołałoby zintegrowanie .NET 5 z Windows 10, należy zacząć od stwierdzenia, że nowy .NET ma pod tym względem mniej wspólnego z poprzednim Frameworkiem, a więcej z Javą.

Programy napisane w Javie nie integrowały w sobie całego środowiska statycznie, bo dzięki temu były mniejsze. Java była na tyle powszechna, że był sens zakładać jej obecność na komputerze konsumenta. A jeżeli jej nie było, mógł sobie ją doinstalować samodzielnie. Dzięki temu program dalej ważył 2MB, a nie 72 i można go było szybciej pobrać domowym internetem roku 2005.

Efektem tego podejścia często był zbiór "Jav": JRE 1.5.0, a obok niego 1.6.0, 1.6.13 i 1.7.1. Teoretycznie potrzebna była tylko jedna, ale niektóre z nich nie umiały zaktualizować poprzednich, a w dodatku kilka aplikacji celowało z konkretną wersję "co do kropki", przez co nie dało się zrobić porządku. W dodatku, część wersji JRE, instalowanych z prawami administracyjnymi, było obarczonych sporymi lukami w zabezpieczeniach. Lądowaliśmy więc z piętnastoma wersjami, wśród których większość była dziurawa, a te najbardziej dziurawe były zazwyczaj nieusuwalne.

Dokładnie to samo stało się z .NET Core w ramach Visual Studio 2017. Regularne aktualizowanie pakietu sprawiało, że w systemie roiło się od SDK i środowisk uruchomieniowych, co stało się problemem do takiego stopnia, że Microsoft wydał dedykowany deinstalator. Obecnie .NET aktualizuje się o wiele grzeczniej niż poprzednicy, w dalszym ciągu jest jednak oprogramowaniem o krótkim terminie ważności i nowe wersje powstają niemal co chwilę.

Programiści powinni celować w najnowszy runtime, ale w praktyce zapewniają oni testowanie tylko na tej wersji... na której ten program napisali. Z punktu widzenia bezpieczeństwa i stabilności, oprogramowanie powinno dostarczać własny runtime i instalować go w swoim lokalnym katalogu, nie wyprowadzając ogólnosystemowych usług i nie rejestrując bibliotek w globalnej przestrzeni. Dzięki temu zachodzi gwarancja, że działają rzeczywiście z tym, z czym ją przetestowano. System nie jest przy okazji wzbogacany o kolejne biblioteki, które trzeba łatać – to dobra wiadomość w przypadku porzucenia wsparcia. Oczywiście, wymaga to od producentów, by periodycznie przebudowywali swoje programy z nowszymi bibliotekami.

A to, że program waży 60 a nie 6 megabajtów? Cóż, żyjemy w rzeczywistości w której komunikator na telefony waży dwieście! Bezpieczeństwo i porządek zapewniane przez dostarczanie własnego środowiska uruchomieniowego przeważają nad problemem ciężkości. Zgodzą się z tym zarówno (świadomi) programiści jak i opiekunowie końcówek, którzy załapali się w swojej karierze na konieczność pilnowania aktualności wtyczek Flash, Java, Air, Silverlight, QuickTime oraz góry innych runtime'ów, bez czego użytkownicy byli narażeni na ataki. Swoją drogą, aplikacje smartfonowe ważą, ile ważą między innymi dlatego, że dostarczają własne biblioteki. To akurat efekt fragmentacji Androida. (Czytelnicy zwracają uwagę, że nie jest to uniwersalna prawda: „delta” funkcjonalna jest dostarczana i aktualizowana oddzielnie)

.NET 5 jest dziś aktualizowany, ale nie dostarczany przez Windows Update. Biorąc pod uwagę konsekwencje stosowania odmiennego modelu oraz dzisiejszą dynamikę dystrybucji oprogramowania, wydaje się to być dobrym podejściem. Zarówno w przypadku .NET, jak i PowerShella.