Między .NET Framework a .NET Core – otwierając kod Microsoft otwiera drzwi do piekła DLL
Zapowiedź uwolnienia frameworka .NET, wraz z wydaniem jegooficjalnej wersji na Linuksa i OS X, zaskoczyła chyba wszystkich. Zprzedstawianych początkowo informacji trudno było jednakwywnioskować, jaki kształt przyjmie opensource'owa wersja taklubianego przez programistów środowiska. Sporo w tej kwestiirozjaśnił wpisImmo Landwertha, menedżera Microsoftu odpowiedzialnego za toprzedsięwzięcie.
Przypomnijmy: fundamentem .NET-u jest środowisko uruchomienioweCLR (Common Language Runtime), w którym uruchamiany jest kod pisanyw językach takich jak C#, Visual Basic czy IronPython. Do tegodochodzi zestaw bibliotek programistycznych, na czele z zawierającąstandardowe typy i funkcje BCL (Base Class Library), oraz zbudowanychna nich frameworków, takich jak desktopowe Windows Forms czyserwerowe ASP.NET.
Potrzeba wprowadzenia .NET na nowe platformy, np. mobilne (WindowsPhone) czy przeglądarkowe (Silverlight) doprowadziła do powstanianiekompatybilnych ze sobą wersji .NET. Z czasem problem siępogarszał, tak że kod pisany dla Windows Phone 7 okazał się byćniekompatybilny z Windows Phone 8. Do pewnego stopnia producentpróbował rozwiązać to wprowadzeniem tzw. PCL (Portable ClassLibraries), zawierających tylko te klasy .NET, które działają nawybranym zbiorze platform. Było to jednak rozwiązanie tymczasowe, wpraktyce bowiem nie zapewnia ono kompatybilności, lecz jedynieuniemożliwia wywołanie interfejsów, które mogłyby uczynić kodniekompatybilnym.
Następną próbą były Universal Apps, zaprezentowane nategorocznej konferencji BUILD – ale i one nie gwarantowałyzgodności, a jedynie możliwość zapakowania do aplikacjispecyficznego dla danej platformy kodu. Uzyskiwaliśmy kompatybilnośćaplikacji z perspektywy użytkowników, ale nie z perspektywyprogramistów, których skazywano na dodatkową pracę.
Przełomem w tej sprawie ma być .NET Core, czyli zmodularyzowanawersja .NET Frameworku. Zawiera on Base Class Library wspólną dlawszystkich platform (nie tylko microsoftowych, ale też dla Linuksa iOS X), mimo skrajnych często nawet różnic między nimi. Wspólnedla wszystkich platform są też kompilatory i środowiskouruchomieniowe, wykorzystujące m.in. nowe optymalizacjeJust-in-Time. Drobne różnice zaczynają się na poziomie stykuimplementacji z rdzeniem. Obecnie gotowe są dwie takieimplementacje, dla .NET Native (czyli kompilowalnych do natywnegokodu aplikacji .NET rozpowszechnianych przez Windows Store) i ASP.NET5 (czyli aplikacji serwerowych). Dodają one po prostu interfejsyspecyficzne dla danego zastosowania – np. .NET Native ma APIzapewniające interoperacyjność z WinRT, zaś ASP.NET 5 API służącedo obsługi wzorców projektowych MVC.
Najciekawszy w .NET Core wydaje się być nowy model wdrażaniaaplikacji. Biblioteki będą dostarczane jako pakiety NuGet, znanedobrze programistom korzystającym z Visual Studio – służą onedo importowania kodu .NET do projektów. Zamiast instalować ogólnyzbiór bibliotek na poziomie systemu, często niekompatybilnych zaplikacją potrzebną użytkownikowi, aplikacjom będzie towarzyszyłotylko to, czego potrzebują. Skończy się konieczność instalowania.NET Frameworka przez użytkowników.
Nie do końca jednak wiadomo jeszcze, jak Microsoft chce sobieporadzić z ewentualnymi problemami z bezpieczeństwem – co robić,jeśli poszczególne pakiety NuGet będą zawierały luki? Oddzielnezaś ich aktualizowanie może doprowadzić do niekompatybilnościposzczególnych komponentów. Póki co Redmond obiecuje przygotowaniecztery razy w roku takich całościowych wydań .NET Core,testowanych pod kątem kompatybilności pakietów. Cynicy już mówiąjednak o tym, że doczekamy się powtórki z historii, znanej pewniestarszym czytelnikom jako PiekłoDLL – aplikacje będą żądały bibliotek A, B i C wkonkretnych wersjach, ale biblioteka B niezbędna do działaniabiblioteki C może nie być zgodna z biblioteką C.
A co z klasycznym .NET Frameworkiem? Z tego co Landwerth pisze,wygląda na to, że powoli odchodzi do lamusa, przynajmniej naserwerach. Póki co .NET Core w ma być podzbiorem .NET Frameworka,nie będzie tu żadnych różnic, ale z czasem .NET Core zacznie byćaktualizowany szybciej niż .NET Framework, tak że w pewnym momenciepojawią się funkcjonalności dostępne wyłącznie w .NET Core. Taksamo na razie aplikacje desktopowe, pisane pod WPF (WindowsPresentation Foundation) wciąż jednak będą korzystały z .NETFrameworka. W razie gdyby doszło do konieczności współdzieleniakodu między oprogramowaniem desktopowym, mobilnym i serwerowym,Microsoft obiecuje dostarczyć niezbędne biblioteki PCL.
Z kolei jednak aplikacje .NET Native, jakie mają zdominowaćWindows Store nie będą współpracowały z .NET Frameworkiem, gdyżjest on niewystarczająco modularny. Dołóżmy do tego jeszczezapowiadane oficjalne wsparcie dla Mono – niezależnejimplementacji .NET dla uniksopodobnych systemów – i widać, że toco miało ułatwić życie programistom może równie dobrze ichzdezorientować.
Jeśli to ma tak wyglądać, to zadajemy sobie pytanie, jaki jestfaktyczny cel tego wszystkiego. Nowy modularny .NET będzie dalekomniej interoperacyjny niż Java, wciąż jego wyróżnionym,najlepszym środowiskiem będzie Windows. Widać jeszcze pewien senstworzenia .NET Core dla Linuksa, ale jaki jest sens pisania go dlaMaka, skoro OS X praktycznie w ogóle nie jest wykorzystywany jakosystem serwerowy? Desktopowych aplikacji pisanych w .NET Frameworkudla Windows i tak się na Makach z .NET Core przecież nie uruchomi.
