Cały ten świat w okół .NET Core jest jakiś dziwny. W sensie, sam nie wiem, kiedy mam zacząć się nim interesować a kiedy to się mija z celem. Informacje, na które natrafiam są ze sobą sprzeczne, to co było opublikowane miesiąc temu ma się nijak do rzeczywistości. Widać, że to się zmienia i brnie do przodu. Kiedyś będzie już za późno by się tego uczyć lub być na fali. Pytanie tylko kiedy. Jedyną stałą rzeczą jaką obserwuje w .NET Core od miesięcy to tak zwany .NET Standard. I jak się okazuje błędnie go sam powiązywałem stricte z .NET Core.

TL;DR

.NET Standard to zbiór interfejsów, które muszą być zaimplementowane przez wszystkie implementacje .NET na wszystkich platformach. Jest to próba usystematyzowania i ułatwienia pracy autorom bibliotek jak i nam zwykłym programistom.

Co to jest .NET Standard?

Słyszeliście o Portable Class Library (PCL)? Jak nie to się nie macie czym przejmować i sorki, że wam głowę jakąś dziwną nazwą zawracam. Jeżeli zaś słyszeliście to możecie o tym zapomnieć, bo to już przeżytek :) Ok, PCL to nic innego jak sposób dostarczania bibliotek, które są cross platform. Ogólnie chodziło oto, że zaznaczało się listę platform, na które chciało się napisać aplikację a nasz tooling ograniczał nam dostępne API jakie możemy wykorzystywać. Dzięki czemu mieliśmy pewność, że nasz kod jest przenaszalny i będzie działał na kilku platformach.

PCL działało na zasadzie “join”, udostępniało tylko to co było wspólne. .NET Standard ma za zadanie działać odwrotnie. On ustala minimum, które wszystkie platformy muszą implementować. Ma aspiracje do bycia Base Class Library (BCL), na bazie którego będą budowane specyficzne API czy Class Library/Aplikacje. Na przykład ASP.NET czy ASP.NET Core to już jest aplikacja – jedna działająca pod implementacją .NET Standard w Full .NET Framework, druga pod .NET Core na Windows, Linux i Mac.

Czyli ogólnie ma to być podstawowa biblioteka, która będzie wykorzystywana przez wszystkie możliwe implementacje .NET teraz i w przyszłości. Będzie definiowała ona podstawowe API, które POWINNO być zaimplementowane gdzie indziej. Dzięki czemu jak piszemy kod z wykorzystaniem .NET Standard wiemy, że zadziała on wszędzie tam, gdzie dana wersja .NET Standard jest zaimplementowana. Inaczej można sobie to wyobrazić jako okrojone mscorlib.dll które jest dostępne dla wszystkich wersji .NET i wszystkich platform (mobilne, systemy operacyjne itp.)

Aspiracje wielkie bym powiedział. Idea też słuszna. Bo jak tak pomyśleć to ten .NET Framework i tak miał już z 20 różnych implementacji – SL, Compact, Micro, Mono, Universal Apps, Windows Phone, Windows Phone Silverlight… oj i wymieniać ich. I każdy za każdym razem był okrojoną wersją poprzedniego, ale w pełni zaimplementowaną i taką która trzeba było wspierać.

Pisanie w ogóle takiego kodu było masakrą, wszędzie #if bo jakieś metody nie ma, inaczej się nazywa itp. .NET Standard ma zaś załatwić ten problem, w sensie, NO MORE #if. Czy mu się uda to inna sprawa.

Najbardziej skomplikowaną rzeczą w .NET Standard to to, w jaki sposób działają typy danych. Mianowicie chodzi o to, że niezależnie od tego jaka jest ich implementacja, działały one tak jak tego zakładamy. To, żeby object działał zarówno na Core jak i na Full. Aby to było możliwe, następuje type forwarding. Dlaczego to jest skomplikowane? Bo to chyba jedyny techniczny aspekt tego całego pomysłu ;) Ogólnie zabawa polega na tym, że .NET Standard robi type forwarding do typów w odkreślonych implementacjach. Ale dodatkowo, jak jesteśmy w kontekście .NET Standard to my nie dostajemy na przykład mscorlib.dll tylko jej fasadę, która robi type forwarding na .NET Standard a ten robi na mscorlib.dll który już jest implementacją. Zakręcone? Tak. I ok, na tym zakończmy.

Czemu piszesz o czasie przyszłym?

Bo jak na razie jak to wszystko z Core, .NET Standard jest w wersji beta albo i alfa. Dopiero wersja 2.0 będzie wersją jakakolwiek rozsądną. Miała ona wyjść już teraz, a wyjdzie pod koniec roku. Ale i tak wersja 2.0 nie będzie tą wersją, na którą czekamy. To znaczy, .NET Standard zakłada, że wszystkie metody mają być zaimplementowane. Niby twórcy już piszą, że to nie możliwe dla wszystkich istniejących typów, ale… dla mnie osobiście to oznacza tyle, że wciąż będziemy pisać #if a jak tak to… sorki. Problem nie został rozwiązany tylko zmienił on nazwę.

Jednak, jeżeli MS to przyciśnie to mamy szanse w końcu uzyskać implementację i wersję .NET Standard w której wszystkie metody będą zaimplementowane. Minusem i problemem jaki widzę to jest to, że każda kolejna wersja buduje na bazie poprzedniej. Czyli 2.0 będzie miał wszystko to co 1.6 plus kilka nowych rzeczy. A to znaczy, że coś co raz zostało zrobione jako PlafromNotSupportedException tak może pozostać do końca dni. A to też oznacza, że hacki w kodzie wciąż będą potrzebne. Dla przykładu już teraz .NET Framework w wersji pełnej na windows, nie wspiera 49 metod z .NET Standard. To jak full framework tego nie wspiera to jaka implementacja będzie wspierała wszystkie? :)

Tak wiem, 49 to mało biorąc pod uwagę wszystkie inne zaimplementowane, ale te 49 dla niektórych mało dla drugich to dużo.

Czy warto inwestować czas w .NET Standard?

Boje się powiedzieć tak. Ale na rozsądek będzie lepiej jak Twój kod będzie współgrał z .NET Standard niż jakby miał z nim nie współgrać. Przynajmniej wtedy wiesz, że Twój kod zadziała wszędzie. A to znaczy, że wszystkie biblioteki które będą wykorzystywały tylko i wyłącznie .NET Standard lub inne biblioteki korzystające .NET Standard będą mogłoby być wykorzystywane w każdym projekcie czy to na linuxa, czy na telefon czy też na IoT.

Podsumowanie

.NET idzie do przodu, czy .NET Standard się przyjmie i zostanie na dłużej? Ciężko powiedzieć. Na razie jest z tym niezłe zamieszanie, numery wersji i wersji implementacji mogą przysporzyć zawrotu głowy. Do tego wersja 2.0 której jeszcze niema a już wiadomo, że nigdzie w pełni nie będzie zaimplementowana… bałagan. Ale może w końcu to się unormuje. Zobaczymy :)

Jeżeli nie szkoda wam waszego czasu to:

 

PODOBNE ARTYKUŁYWIĘCEJ OD AUTORA

7 KOMENTARZE

  1. Z jednej strony ciesze sie ze cos sie dzieje w .NET. Z drugiej cała sprawa z beta, RC, RTM troche mna przeorała czasowo i kasowo u klientow.
    Kwestie toolsow RC -> RTM to temat na … książke. Ogolnie podejcie do pewnych spraw jest ciekawe i chetnie za 10 lat sie dowiem
    co to sie działo pod spodem przy projektowaniu i wypuszczaniu tego produktu. Moje subiektywne odczucie to takie: goscie szczegolnie
    z działu ASP.NET chcieli zrobic cos porzadnie. Taki restart serii cos ala kinowe przeboje. Niestety przyszła ciemna strona (Enterprise)
    i powiedziała wypierdzielać z tym i wracamy do starego (miedzy innymi project.json->msbuild)
    Z mojego punktu widzenia straciłem na całym tym procesie i do .NET Standard i do wersji 2.0 podchodze jak do jeża. Mam jednak nadzieje ze
    2.0 dla .net core bedzie tym samym co 2.0 dla .net full framework. Przypomnie jedynie ze .net 2.0 full framework pojawilo sie na rynku w 2003r.
    Po 14 latach zrobilismy duże koło i ….
    Chyba musze poszukać alternatywy dla .net może go, rust, elm ….

    • jest coś w tym co mówisz. Ale ja jestem ciekaw jak to się im uda i jak to pociągną dalej, więc raz na jakiś czas robię checkin ;) Bo jak zamkną to co chcą osiągnąć to będzie to bardzo fajne.

  3. Mam wrażenie, że wszystko jest zrobione na kolanie, byleby tylko było i żeby można było odtrąbić, że .NET wspiera linuksa (i resztę świata). Ale to tak nie działa. Mam duży .NET Framework, który znam, który jest stabilny i godny zaufania, więc dlaczego mam nagle migrować do kompletnie nowej platformy, do której nie ma materiałów do dogłębnej nauki (z kodu źródłowego uczyć się nie zamierzam, to nie linux, a materiały z konferencji to hello worldy), która zmienia się jak w kalejdoskopie (raz jest json, raz csproj, raz zostawiamy appdomeny, raz usuwamy, raz jest TypedReference, raz nie ma), co do której właściwie nie wiadomo, co z tego będzie. Ale hasło marketingowe jest, można krzyczeć o wspieraniu innych platform, tylko że ja teraz nie wiem, czy platforma, której poświęciłem wiele lat będzie sensownie wspierana i czy nie lepiej przeskoczyć na JVM…

  4. Od jakiegoś pół roku mam szczęście (nieszczęście?) być bliżej tzw. bibliotek portable. Ogarnięcie wszystkich tematów profili i różnych ich konfiguracji to była masakra. Teraz przymierzamy się przejścia w pracy na .Net Standard, ale samo przejście, uwzględniając takie tematy jak Jenkins i nugety też jest trudne. Mam nadzieje, że jest to rozwiązanie na dłużej. Mnie osobiście niepokoi fakt, że .Net Standard Library używa project.json, który jest już passé i boję się myśleć, co MS wsadzi tam w kolejnej wersji.

    A co do samego przejścia, to jeśli się korzysta z projektów wymagających portable (np. Xamarin), to niestety jeśli chcemy być na bieżąco z paczkami, musimy wskoczyć do tego tematu.

  5. Sam sie zastanawiam, czy nie zwiać do Java, bo podejscie Microsoft mnie wk… denerwuje.
    Wymyślają jakieś json do projektów – po co jak maja xml i tam można wstawiać komentarze.
    Robią dwie gałęzie EF – po co? Mapowanie typów? Po co? Czy oni chcą to zrobić na 8-bitowce? I tak wszędzie są procki 32 bit a nawet 64.
    Popieprzyli numerację net standard vs net framework, nie mogli wydać po prostu net framework 4.5 na linuksa i osx (oczywiście bez tego, czego nie ma na tych systemach) i po sprawie?
    Przecież część net framework napisana jest w c#.
    Poza tym mają chore decyzje projektowe, np. jest/był babol, że jak w windows phone chciało się skorzystać z regex kompilowanych to na chłopski rozum jak os nie obsłuży, to powinny działaś jak niekompilowane, a tam wywalało wyjątek?
    Ja już nie wierzę w to, ze im to wyjdzie, przecież robi to firma, która nie ogarnęła windows phone . Aha, i na nowo odkryli kompilację z kodu do klasycznego exe :-D
    Net core byłem żywo zainteresowany, ale tak zabałaganili, ze odpuściłem sobie.
    Ktoś w necie napisał, że net core to dobry krok, bo modularyzacja, etc. ale sorry, czy jednolite środowisko wykonawcze w rozmiarze nawet 70MB to problem dla współczesnych maszyn?
    Do mikrokontrolerów i tak tego nikt nie użyje, bo szkoda mocy na net framework. Zaś w wersji dla serwerów, desktopów, telefonów to żaden koszt.
    Ciekaw jestem jakie kwiatki wychodzą przy mssql dla linuksa.

Comments are closed.