r   e   k   l   a   m   a
r   e   k   l   a   m   a

Między .NET Framework a .NET Core – otwierając kod Microsoft otwiera drzwi do piekła DLL

Strona główna AktualnościOPROGRAMOWANIE

Zapowiedź uwolnienia frameworka .NET, wraz z wydaniem jego oficjalnej wersji na Linuksa i OS X, zaskoczyła chyba wszystkich. Z przedstawianych początkowo informacji trudno było jednak wywnioskować, jaki kształt przyjmie opensource'owa wersja tak lubianego przez programistów środowiska. Sporo w tej kwestii rozjaśnił wpis Immo Landwertha, menedżera Microsoftu odpowiedzialnego za to przedsięwzięcie.

Przypomnijmy: fundamentem .NET-u jest środowisko uruchomieniowe CLR (Common Language Runtime), w którym uruchamiany jest kod pisany w językach takich jak C#, Visual Basic czy IronPython. Do tego dochodzi zestaw bibliotek programistycznych, na czele z zawierającą standardowe typy i funkcje BCL (Base Class Library), oraz zbudowanych na nich frameworków, takich jak desktopowe Windows Forms czy serwerowe ASP.NET.

Potrzeba wprowadzenia .NET na nowe platformy, np. mobilne (Windows Phone) czy przeglądarkowe (Silverlight) doprowadziła do powstania niekompatybilnych 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 producent próbował rozwiązać to wprowadzeniem tzw. PCL (Portable Class Libraries), zawierających tylko te klasy .NET, które działają na wybranym zbiorze platform. Było to jednak rozwiązanie tymczasowe, w praktyce bowiem nie zapewnia ono kompatybilności, lecz jedynie uniemożliwia wywołanie interfejsów, które mogłyby uczynić kod niekompatybilnym.

r   e   k   l   a   m   a

Następną próbą były Universal Apps, zaprezentowane na tegorocznej konferencji BUILD – ale i one nie gwarantowały zgodności, a jedynie możliwość zapakowania do aplikacji specyficznego dla danej platformy kodu. Uzyskiwaliśmy kompatybilność aplikacji z perspektywy użytkowników, ale nie z perspektywy programistów, których skazywano na dodatkową pracę.

Przełomem w tej sprawie ma być .NET Core, czyli zmodularyzowana wersja .NET Frameworku. Zawiera on Base Class Library wspólną dla wszystkich platform (nie tylko microsoftowych, ale też dla Linuksa i OS X), mimo skrajnych często nawet różnic między nimi. Wspólne dla wszystkich platform są też kompilatory i środowisko uruchomieniowe, wykorzystujące m.in. nowe optymalizacje Just-in-Time. Drobne różnice zaczynają się na poziomie styku implementacji z rdzeniem. Obecnie gotowe są dwie takie implementacje, dla .NET Native (czyli kompilowalnych do natywnego kodu aplikacji .NET rozpowszechnianych przez Windows Store) i ASP.NET 5 (czyli aplikacji serwerowych). Dodają one po prostu interfejsy specyficzne dla danego zastosowania – np. .NET Native ma API zapewniające interoperacyjność z WinRT, zaś ASP.NET 5 API służące do obsługi wzorców projektowych MVC.

Najciekawszy w .NET Core wydaje się być nowy model wdrażania aplikacji. Biblioteki będą dostarczane jako pakiety NuGet, znane dobrze programistom korzystającym z Visual Studio – służą one do importowania kodu .NET do projektów. Zamiast instalować ogólny zbiór bibliotek na poziomie systemu, często niekompatybilnych z aplikacją potrzebną użytkownikowi, aplikacjom będzie towarzyszyło tylko to, czego potrzebują. Skończy się konieczność instalowania .NET Frameworka przez użytkowników.

Nie do końca jednak wiadomo jeszcze, jak Microsoft chce sobie poradzić z ewentualnymi problemami z bezpieczeństwem – co robić, jeśli poszczególne pakiety NuGet będą zawierały luki? Oddzielne zaś ich aktualizowanie może doprowadzić do niekompatybilności poszczególnych komponentów. Póki co Redmond obiecuje przygotowanie cztery 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 pewnie starszym czytelnikom jako Piekło DLL – aplikacje będą żądały bibliotek A, B i C w konkretnych wersjach, ale biblioteka B niezbędna do działania biblioteki 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 na serwerach. 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 momencie pojawią się funkcjonalności dostępne wyłącznie w .NET Core. Tak samo na razie aplikacje desktopowe, pisane pod WPF (Windows Presentation Foundation) wciąż jednak będą korzystały z .NET Frameworka. W razie gdyby doszło do konieczności współdzielenia kodu 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 jeszcze zapowiadane oficjalne wsparcie dla Mono – niezależnej implementacji .NET dla uniksopodobnych systemów – i widać, że to co miało ułatwić życie programistom może równie dobrze ich zdezorientować.

Jeśli to ma tak wyglądać, to zadajemy sobie pytanie, jaki jest faktyczny cel tego wszystkiego. Nowy modularny .NET będzie daleko mniej interoperacyjny niż Java, wciąż jego wyróżnionym, najlepszym środowiskiem będzie Windows. Widać jeszcze pewien sens tworzenia .NET Core dla Linuksa, ale jaki jest sens pisania go dla Maka, skoro OS X praktycznie w ogóle nie jest wykorzystywany jako system serwerowy? Desktopowych aplikacji pisanych w .NET Frameworku dla Windows i tak się na Makach z .NET Core przecież nie uruchomi.

© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.