Kompatybilność z wersjami .NET Framework

Kompatybilność z wersjami .NET Framework określa, które wydania tej platformy obsługują kod uruchamiany w bazie.

Jak rozumieć zgodność aplikacji z .NET Framework

Kompatybilność z wersjami .NET Framework oznacza zgodność kodu pośredniego, bibliotek oraz ustawień aplikacji z konkretnym środowiskiem uruchomieniowym zainstalowanym w systemie Windows. Program napisany dla określonej wersji może wymagać obecności odpowiedniego środowiska, nawet jeśli sam plik wykonywalny ma poprawną strukturę i uruchamia się na innym komputerze. Znaczenie ma również to, czy aplikacja korzysta wyłącznie z publicznego interfejsu platformy, czy odwołuje się do zachowań, bibliotek albo składników dostępnych tylko w wybranym wydaniu.

.NET Framework jest platformą przeznaczoną przede wszystkim dla systemu Windows. W jej skład wchodzą między innymi środowisko uruchomieniowe CLR, biblioteka klas oraz komponenty dodatkowe, takie jak ASP.NET, Windows Forms, Windows Presentation Foundation i Windows Communication Foundation. Sama nazwa wersji nie opisuje wszystkich zależności aplikacji. Program może wymagać określonego profilu, biblioteki systemowej, dodatku językowego lub elementu instalowanego osobno, dlatego zgodność ocenia się na podstawie rzeczywistego celu kompilacji i komunikatów środowiska.

Różnice między generacjami platformy

Wersje .NET Framework 2.0, 3.0 i 3.5 korzystają z rodziny CLR 2.0. Wydanie 3.0 rozszerzyło platformę między innymi o Windows Presentation Foundation, Windows Communication Foundation, Windows Workflow Foundation i Windows CardSpace, natomiast .NET Framework 3.5 dodał kolejne biblioteki, w tym obsługę LINQ. W praktyce instalacja .NET Framework 3.5 w systemach, które ją obsługują, może dostarczać również składniki wcześniejszych wydań z tej samej rodziny, ale nie oznacza to automatycznej zgodności z każdą aplikacją korzystającą z nietypowych rozszerzeń.

.NET Framework 4, 4.5, 4.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2 i 4.8 należą do rodziny CLR 4. Wydania od 4.5 wzwyż były dostarczane jako aktualizacje instalacji .NET Framework 4 i zastępowały wcześniejsze wydanie 4.x w modelu aktualizacji w miejscu. Nie można jednak traktować wszystkich generacji jako jednego środowiska: aplikacja przeznaczona dla .NET Framework 3.5 może wymagać aktywowania tej funkcji systemu, a aplikacja skompilowana dla .NET Framework 4 lub nowszego potrzebuje odpowiedniej gałęzi CLR 4.

Wydanie .NET Framework 4.8 jest ostatnią wersją tej platformy, natomiast .NET, dawniej nazywany .NET Core, jest odrębną linią technologiczną. Aplikacja dla .NET 6, .NET 7, .NET 8 albo innego współczesnego wydania .NET nie jest aplikacją dla .NET Framework i wymaga właściwego środowiska uruchomieniowego. Zmiana nazwy platformy nie jest jedynie zmianą numeru wersji, ponieważ różnią się model wdrażania, dostępne biblioteki, systemy operacyjne i sposób publikowania aplikacji.

Target framework, CLR i ustawienia uruchamiania

Podczas kompilacji projekt otrzymuje docelową platformę, określaną jako target framework. W starszych projektach może to być na przykład .NET Framework 3.5, .NET Framework 4.0 lub .NET Framework 4.8. Kompilator sprawdza wtedy dostępność referencji z odpowiadającego zestawu deweloperskiego, zwanego targeting packiem lub developer packiem. Zainstalowanie samego środowiska uruchomieniowego na komputerze nie zawsze wystarcza do zbudowania programu, ponieważ do kompilacji potrzebne są również właściwe pliki referencyjne i narzędzia.

Informację o wymaganej wersji można częściowo odczytać z metadanych pliku wykonywalnego oraz konfiguracji aplikacji. W pliku konfiguracyjnym element <startup> z wpisem <supportedRuntime> może wskazywać obsługiwane środowisko CLR i zachowanie przy uruchamianiu. Dla aplikacji korzystających z CLR 4 typowe jest wskazanie wersji v4.0, choć dokładna interpretacja zależy od konfiguracji i rodzaju aplikacji. Należy także rozróżnić wersję CLR od wersji bibliotek .NET Framework: kilka wydań platformy może korzystać z tego samego głównego środowiska uruchomieniowego, ale wprowadzać zmiany w bibliotekach, poprawki zgodności i nowe zachowania.

Ważnym elementem jest mechanizm przekierowania wiązań zestawów, czyli assembly binding redirect. Jeśli różne biblioteki wymagają odmiennych wersji tego samego zestawu, konfiguracja aplikacji może przekierować ładowanie do jednej wersji zgodnej z programem. Bez takiego przekierowania pojawiają się błędy typu FileLoadException, FileNotFoundException albo FileLoadException z informacją o niezgodności manifestu. Nie każda awaria oznacza jednak brak .NET Framework. Przyczyną może być uszkodzona instalacja, brak zależności natywnej, niezgodna architektura x86 lub x64, uprawnienia systemowe albo błąd samej aplikacji.

Weryfikacja zgodności na laptopie i komputerze PC

Sprawdzanie zgodności powinno rozpocząć się od ustalenia, której dokładnie wersji wymaga aplikacja, oraz od odczytania komunikatu pojawiającego się podczas uruchamiania. W systemie Windows wersję .NET Framework 4.5 i nowszą można rozpoznać między innymi na podstawie wartości Release w kluczu rejestru HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full. Wartość ta jest numerem technicznym używanym do rozpoznawania wydania, a nie zwykłym numerem wersji wyświetlanym w nazwie produktu. Dla starszych wersji sprawdza się odpowiednie podklucze instalacji, obecność składników systemu oraz stan funkcji .NET Framework 3.5.

Przy analizie programu trzeba ustalić, czy jest on przeznaczony dla CLR 2.0, CLR 4, czy dla współczesnego .NET. Następnie sprawdza się plik konfiguracyjny, zależności zestawów, architekturę procesu i zgodność systemu Windows. Aktualizacja .NET Framework może usunąć problem wynikający z brakującej poprawki lub biblioteki, ale nie naprawi kodu odwołującego się do nieistniejącej funkcji ani konfliktu między bibliotekami. W środowisku produkcyjnym każdą zmianę należy poprzedzić uruchomieniem aplikacji i testem najważniejszych funkcji.

Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów i komputerów PC, w tym diagnostykę problemów z uruchamianiem aplikacji, brakującymi składnikami systemu oraz niezgodnością zainstalowanego oprogramowania. Prawidłowa diagnoza polega na rozdzieleniu problemu platformy .NET Framework od błędu programu, konfiguracji Windows lub uszkodzenia systemu, aby zastosowane działanie odpowiadało rzeczywistej przyczynie.