Blog Teo IT Social sciences

.NET współcześnie

Technologia .NET posiada dość zawiłą terminologię i historię, która zmieniała się na przestrzeni lat, wprowadzając różne wersje i nazwy skupione wokół tego środowiska. W tym wpisie postaram się uporządkować i wyjaśnić chronologię, ewolucję i definicję terminów, które kryją się, bądź kryły się za nazwą .NET.

Historia kolejnych generacji platformy wygląda następująco:

  • .NET Core 1.x
  • .NET Core 2.x
  • .NET Core 3.x
  • .NET 5
  • .NET 6
  • .NET 7
  • .NET 8
  • .NET 9

Programy napisane w wersjach wcześniejszych niż np. .NET 9 mają zapewnioną kompatybilność wsteczną i powinny dać się skompilować przez najnowszą wersję. Mogą jednak wymagać drobnych poprawek w celu zapewnienia kompatybilności, jednak generalnie mając program napisany przykładowo w .NET Core 3.x i drugi napisany w .NET 6 skompilujemy w środowisku .NET 8, czyli późniejszym, ale program napisany w .NET 9 może nie skompilować się w .NET 8 i wersjach wcześniejszych.

Czym jest .NET Core?

Współczesne projekty programistyczne często muszą uwzględniać rozwiązania chmurowe i mobilne, stąd system Windows jako główny system operacyjny dostępny na większości komputerów na świecie stracił na znaczeniu na korzyść systemów Android, iOS oraz dostawców usług w chmurze: AWS, Google Cloud, Azure (zresztą samego Microsoftu), a także rosnącej popularności systemu MacOS i specyficznych zastosowań w pełni konfigurowalnego, otwarto-źródłowego Linuxa. Przyczyn można pewnie wymienić więcej, jednakże powodem powstania .NET Core była motywacja aby platformę .NET Framework dedykowaną tylko systemowi Windows uczynić dostępną dla innych platform. Platforma .NET Core nie jest kompatybilna z .NET Framework i programy pisane w .NET Core nie mogą być przeniesione do .NET Framework.

Dlaczego nie ma wersji .NET 4?

Otóż aby wyraźnie rozróżnić opisaną genealogię współczesnej, najnowszej platformy .NET 9 od odmiennej względem niej rodziny, która nazywa się .NET Framework. Najnowsza wersja .NET Framework zatrzymuje się na numerze 4.x. Powodem, dla którego nie istnieje wersja .NET 4 jest intencja wyraźnego rozróżnienia platformy .NET od platformy .NET Framework.

Czym jest .NET Framework?

W skrócie należy zaznaczyć, że w przeciwieństwie do wieloplatformowego .NET wywodzącego się z .NET Core, .NET Framework działa tylko w systemie Windows. Jest w nim domyślnie zainstalowany od wersji .NET Framework 4.5.2 i nie trzeba instalować go z zewnątrz. Nie są planowane żadne aktualizacje, więc rozwój tej technologii zakończono na wersji 4.8, jednak była to technologia aktywnie wykorzystywana w systemie Windows, więc firma Microsoft zapewnia wsparcie dla najnowszej wersji, z powodu istnienia obecnie wielu programów napisanych właśnie w .NET Framework. Z powodu tej powszechności nie powinno się też wprowadzać dużych zmian do tej technologii, nawet w przypadku poprawek błędów. Za pomocą środowiska .NET 9 lub .NET Core 3 jest możliwa kompilacja aplikacji stworzonej w .NET Framework, ale najczęściej wymaga to dostosowania implementacji, ze względu na różnice występujące pomiędzy tymi rodzinami. .NET 9 i .NET Framework różnią się między sobą zestawem wspieranych i posiadanych przez siebie bibliotek oraz środowiskiem, na którym mogą pracować. .NET Framework wpiera system Windows, natomiast wieloplatformowy .NET dodatkowo:

  • MacOS
  • Linux
  • Android i iOS
  • Przeglądarki internetowe (poprzez WebAssembly)

Do starszych wersji środowiska .NET oprócz opisanego .NET Framework należą także projekty:

  • Mono – stanowi implementację open source dla platformy .NET Framework przystosowaną do uruchomienia platformy w środowiskach takich jak: Android, Windows Phone, GNU/Linux, BSD, OS X, Windows, Solaris, PlayStation 3, Nintendo Wii Xbox 360. Posiada jednak mniejszą funkcjonalność niż .NET Framework.
  • Xamarin – „wywodzi się z projektu Mono, pozwala tworzyć natywne aplikacje dla systemu Android, iOS i macOS przy użyciu kodu .NET i interfejsów użytkownika specyficznych dla platformy. Zestaw narzędzi Xamarin.Forms umożliwia tworzenie natywnych aplikacji ze współdzielonym kodem interfejsu użytkownika napisanym w języku C# lub XAML.”1
  • .NET Standard – „to formalna specyfikacja interfejsów API platformy .NET, które są dostępne w wielu implementacjach platformy, pozwala bibliotece używać większej liczby interfejsów API, ale oznacza to, że można jej używać tylko w nowszych wersjach .NET. Celowanie w niższą wersję zmniejsza liczbę dostępnych interfejsów API, ale oznacza, że ​​biblioteka może działać w większej liczbie miejsc. NETStandard 2.1 jest nieodłącznie związany z NET 8.0”. Implementacja standardu w wersji 2.1 została także zachowana w .NET Core 3.0, Mono i Xamarin, język C# 8.0 również jej wymaga, natomiast w .NET Framework 4.8 nie spełniono wymagań standardu w wersji 2.1 Zaleca się stosowanie .NET standard szczególnie jako platformy wspólnej w projektach używających różnych technologii z rodziny .NET np. .NET Framework i .NET Core lub .NET Framework i .NET 8. Microsoft zapewnia, że nie zostaną wydane żadne nowe wersje biblioteki i pozostanie ona niezmienna.2 Wraz z pojawieniem się .NET 5 znaczenie .NET Standard spadło, z powodu ujednolicenia całego środowiska do jednej wersji .NET, jednak standard jest nadal istotny w próbach integracji starszych implementacji pochodzących z różnych odmian starszej platformy .NET.

Obecnie Mono, Xamarin i .NET Standard nie są już oficjalnie wspierane. Współczesny .NET 9 bazuje na tych projektach i posiada biblioteki z nich pochodzące.

A nieoficjalne wsparcie?

.NET jest projektem open source, możliwy jest dalszy rozwój jego komponentów przez społeczność wokół nich skupioną, nawet gdy oficjalne wsparcie Microsoftu dla takiej technologii zakończy się. Przykładem jest WCF (Windows Communication Foundation), wprowadzony z .NET Framework 3.0 i usunięty z nowoczesnej platformy .NET ze względu na silne powiązanie z systemem Windows i brak charakteru przenośności na odmienne systemy. Pomimo braku oficjalnego zainteresowania technologią ze strony firmy Microsoft społeczność postanowiła dalej ją rozwijać jako projekt Core WCF należący do rodziny WCF Foundation. Dzięki wsparciu społeczności technologia WCF okazała się pomocna i możliwe stało się przeniesienie części usług z .NET Framework do nowego .NET. Technologie skupione wokół .NET są rozwijane nie tylko przez Microsoft, ale też społeczność skupioną wokół nich.

Zarysowałem listę wydań kolejnych wersji prowadzących do współczesnego .NET teraz przedstawię krótką historię .NET Framework.

.NET Framework ewoluował wraz z rozwojem systemu Windows. Pierwszy system miał nazwę Windows 1.0 został wydany w 1985 r. Programowało się w C i korzystało tylko z trzech bibliotek DLL – kernel, user i GDI. W Windows 95 biblioteki DLL zgrupowano w nazwę Win32 API. Dalszy etap objął wprowadzenie języka Visual Basic, który umożliwiał programowanie low code, metodą „przeciągnij i upuść”. Pierwsza wersja .NET Framework została wydana w 2002 r. wraz z językiem C#, choć możliwe było dalej programowanie w Visual Basic, a także podejście low code. W tym środowisku istniały dwie technologie:

  • Windows Forms – dla aplikacji systemu Windows
  • Web Forms – dla aplikacji webowych

następna wersja .NET Framework 3.0 wniosła:

  • WPF (Windows Presentation Foundation) – nowsze od Windows Forms rozwiazanie do tworzenia aplikacji systemu Windows
  • WCF – już opisane wyżej
  • WF (Windows Workflow)

W 2012 r. wprowadzono Windows Store wraz z systemem Windows 8

W 2015 r. Windows 10 wprowadza platformę UWP (Universal Windows Platform) zbudowaną na bazie Windows Store, umożliwiającą programowanie m. in. w języku C# oraz korzystającą z nowoczesnego .NET. Platforma UWP umożliwia tworzenie aplikacji tylko dla Windows 10 i 11, Xbox, Windows Mixed Reality, pozwala również na dostęp do WinRT API3, ale nie pozwala na pełny dostęp do systemu operacyjnego, dlatego UWP jest rozwiązaniem unikanym przez programistów. Z tego powodu Microsoft stworzył technologię Windows App SDK4, która wcześniej znana była pod nazwą WinUI 3 oraz Reunion. Ta technologia kompensowała wcześniejsze ograniczenia UWP, jednocześnie zachowując jej dotychczasową funkcjonalność. Obecnie Windows App SDK nie zastępuje:

  • Windows SDK
  • .NET wraz z komponentami Windows Forms i WPF
  • Win32 API

stanowi natomiast ich uzupełnienie w tworzeniu rozwiązań dla systemu Windows5

Nasuwa się pytanie: w jaki sposób współczesny .NET może być użyteczny w nowych systemach Windows?

Otóż wersja środowiska .NET dla systemu Windows zawiera dodatkowe biblioteki, których brakuje w wersjach dla innych systemów operacyjnych. Są to: Windows Forms oraz WPF, które wraz z pakietem Windows Desktop Pack umożliwiają współczesnej platformie .NET rozwój nawet starszych aplikacji wykorzystywanych w nowych wersjach systemu Windows. Jedyne ograniczenie to obsługiwane wersje systemu: Windows 10 i 11 oraz Windows Server6.

Jaki jest współczesny .NET?

W porównaniu do .NET Framework współczesny .NET jest bardziej modułowy, dodatkowo jego waga jest mniejsza, ponieważ usunięto większość starych bibliotek składających się na .NET Framework.

  • Moduł webowy – o nazwie ASP.NET Core, na który składają się zagregowane technologie: ASP.NET MVC, ASP.NET Web API, SignalR, gRPC, spośród których usunięto starsze technologie: ASP.NET Web Forms oraz WCF i WF
  • Moduł baz danych – obsługiwany przez bibliotekę Entity Framework Core, bazującą na Entity Framework 6, został odchudzony w porównaniu do wersji 6, dodatkowo oprócz mapowania obiektowo-relacyjnego dodano wsparcie dla baz danych NoSql, w tym chmurowych np. Microsoft Azure Cosmos DB

Środowisko uruchomieniowe .NET

Środowisko .NET składa się w dwóch modułów:

  • Biblioteki klas BCL
  • Środowiska uruchomieniowego CLR, na które składają się dwa moduły: CoreCLR oraz Mono. CoreCLR zostało zoptymalizowane do pracy na serwerach i komputerach stacjonarnych, natomiast Mono do pracy w urządzeniach o ograniczonych zasobach takich jak urządzenia mobilne i przeglądarki internetowe.

Kod źródłowy języka C# może być skompilowany do kodu pośredniego IL (intermediate language), mamy wówczas kompilację JIT (just-in-time), w której środowisko uruchomieniowe CoreCLR pobiera kod pośredni i kompiluje go do kodu maszynowego danej platformy. Takie podejście umożliwia napisanie jednego kodu kompilowanego do IL, który może być uruchamiany na wielu różnych platformach, przez dedykowane konkretnym platformom wersje CoreCLR tłumaczące ten sam kod IL. Dzięki podejściu JIT środowisko uruchomieniowe .NET może optymalizować w czasie rzeczywistym wykonywanie kodu na docelowej maszynie. Podczas pracy JIT kod IL jest kompilowany do docelowego kodu maszynowego i wykonywany w czasie rzeczywistym przez środowisko docelowe łącząc zalety procesu kompilacji i interpretacji. Należy zaznaczyć, że kod w JIT jest kompilowany, a nie interpretowany, podstawowa różnica polega na wykonywaniu kodu. Interpreter interpretuje i wykonuje kod, a w przypadku JIT kompilator nie wykonuje kodu. Kod jest wykonywany dopiero na maszynie docelowej, ale w czasie rzeczywistym względem postępu procesu kompilacji.7

Istnieje także wariant kompilacji AOT (ahead-of-time) w środowisku .NET np. w przypadku plików WASM (WebAssembly) dla przeglądarek internetowych lub platform o ograniczonych zasobach sprzętowych. Kompilacja AOT umożliwia tłumaczenie kodu w języku C# bezpośrednio na kod maszynowy z pominięciem IL. w tym przypadku uruchomienie kodu nie wymaga obecności środowiska uruchomieniowego .NET na docelowej platformie, ponieważ tłumaczenie implementacji do kodu pośredniego nie jest wymagane. Choć rozmiar kodu maszynowego jest większy niż w przypadku kompilacji JIT ze względu na obecność zlinkowanych bibliotek i zależności, podejście AOT ma następujące zalety:

  • możliwość kompilacji gdy JIT jest niemożliwe np. w systemie iOS
  • czas uruchomienia aplikacji ma znaczenie np. wywoływanie funkcji chmurowych lub uruchamianie wielu małych instancji o krótkim czasie życia
  • mniejsze zapotrzebowanie na pamięć operacyjną np. w urządzeniach IoT
  • potrzeba uruchomienia kodu gdy środowisko .NET jest niedostępne np. kodu biblioteki

  1. https://learn.microsoft.com/pl-pl/previous-versions/xamarin/ ↩︎
  2. https://learn-microsoft-com.translate.goog/en-us/dotnet/standard/net-standard?_x_tr_sl=en&_x_tr_tl=pl&_x_tr_hl=pl&_x_tr_pto=rq&tabs=net-standard-1-0 ↩︎
  3. https://en.wikipedia.org/wiki/Windows_Runtime ↩︎
  4. https://developer.microsoft.com/pl-pl/windows/downloads/windows-sdk/ ↩︎
  5. https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/ ↩︎
  6. https://learn.microsoft.com/pl-pl/dotnet/core/install/windows#supported-versions ↩︎
  7. https://stackoverflow.com/questions/5074145/is-jit-compiler-a-compiler-or-interpreter ↩︎

Opublikowano

w

przez

dstec

Tagi: