Kompatybilność funkcji CLR

Kompatybilność funkcji CLR dotyczy zgodności kodu .NET osadzonego w bazie z wersją środowiska uruchomieniowego serwera.

Na czym polega zgodność kodu SQL CLR

Kompatybilność funkcji CLR w SQL Server oznacza zgodność zarządzanego kodu .NET z mechanizmem Common Language Runtime, który jest osadzony w konkretnej wersji silnika bazy danych. SQL CLR pozwala tworzyć między innymi funkcje, procedury składowane, wyzwalacze, typy danych i agregaty w językach .NET, a następnie wywoływać je z poziomu języka Transact-SQL. Kod nie działa jednak jako niezależny program uruchamiany poza bazą. Jest ładowany przez środowisko CLR kontrolowane przez SQL Server, dlatego znaczenie mają wersja środowiska, dostępne biblioteki, sposób zbudowania zestawu oraz zasady bezpieczeństwa obowiązujące w danym wydaniu silnika.

Zgodność nie ogranicza się do sprawdzenia, czy plik DLL można zaimportować do bazy. Trzeba także ustalić, czy użyte typy, metody i zależności są dostępne w środowisku uruchomieniowym. Zestaw może zostać odrzucony już podczas rejestracji, ale część problemów ujawnia się dopiero przy pierwszym wykonaniu funkcji. Przykładowymi objawami są błędy ładowania zestawu, brak zależności, niezgodność metadanych, wyjątek podczas inicjalizacji typu albo nieobsługiwane wywołanie biblioteki .NET. Dlatego test importu powinien być uzupełniony o rzeczywiste wykonanie wszystkich ścieżek kodu.

Wersja środowiska uruchomieniowego i zależności zestawu

W SQL Server istotna jest generacja CLR używana przez silnik. Starsze wydania SQL Server korzystały z CLR w wersji 2, natomiast SQL Server 2012 i nowsze wykorzystują CLR w wersji 4. Zmiana ta wpływa na sposób ładowania zestawów oraz zgodność z bibliotekami .NET Framework. Kod skompilowany dla wcześniejszej wersji może w niektórych przypadkach działać w nowszym środowisku, ponieważ CLR v4 obsługuje część starszych zestawów, ale nie oznacza to automatycznej zgodności całej aplikacji. Problemem mogą być zależności od konkretnych wersji bibliotek, zmienione zachowanie klas, nieobsługiwane formaty lub założenia dotyczące konfiguracji środowiska.

Przy analizie należy porównać wersję SQL Server, edycję i poziom aktualizacji z informacjami zapisanymi w metadanych zestawu. Pomocne jest sprawdzenie docelowego frameworka w projekcie .NET, referencji dodanych podczas kompilacji oraz tego, czy zależne biblioteki zostały zarejestrowane w bazie. SQL CLR nie powinien zakładać, że dowolna biblioteka obecna na komputerze deweloperskim będzie dostępna dla kodu wykonywanego w silniku. Szczególnej uwagi wymagają biblioteki korzystające z funkcji systemu operacyjnego, natywnego kodu, konfiguracji aplikacyjnej albo plików znajdujących się poza bazą. Aktualizacja SQL Server może zmienić warunki uruchomienia, dlatego zestawy należy ponownie przetestować po migracji.

Poziom dostępu a możliwość wykonania funkcji

SQL CLR rozróżnia trzy poziomy uprawnień zestawu: SAFE, EXTERNAL_ACCESS i UNSAFE. SAFE jest przeznaczony dla kodu o ograniczonym dostępie do zasobów zewnętrznych. EXTERNAL_ACCESS pozwala na określone operacje poza bazą, natomiast UNSAFE obejmuje kod wymagający najszerszych uprawnień, w tym możliwość korzystania z niezarządzanych zasobów. Te poziomy są częścią modelu bezpieczeństwa, ale wpływają również na praktyczną kompatybilność: zestaw może być poprawnie skompilowany, a mimo to nie uruchomić się, ponieważ jego operacje nie mieszczą się w zadeklarowanym poziomie dostępu.

W nowszych wydaniach SQL Server, począwszy od SQL Server 2017, działa mechanizm CLR strict security. Zestawy oznaczone jako EXTERNAL_ACCESS lub UNSAFE są traktowane jako wymagające podwyższonego zaufania, a samo ustawienie właściwości w definicji zestawu nie wystarcza do bezpiecznego uruchomienia kodu. W zależności od sposobu wdrożenia konieczne może być podpisanie zestawu odpowiednim kluczem i utworzenie związanych z nim uprawnień albo jawne dodanie zestawu do listy zaufanych zestawów za pomocą mechanizmu sp_add_trusted_assembly. Przy sprawdzaniu zgodności trzeba więc uwzględnić nie tylko wersję CLR, lecz także ustawienie clr enabled, poziom uprawnień, podpis cyfrowy, zależności oraz politykę zaufania konkretnej instancji.

Diagnostyka błędów kompatybilności SQL CLR

Diagnostykę najlepiej rozpocząć od ustalenia, czy problem występuje podczas tworzenia zestawu, jego aktualizacji, wywołania funkcji, czy dopiero przy obsłudze konkretnego rekordu. Warto odczytać komunikat z SQL Server i sprawdzić pełny łańcuch wyjątków, ponieważ ogólne informacje o niemożności załadowania zestawu często ukrywają brakującą bibliotekę lub niezgodną wersję zależności. Następnie należy porównać definicję obiektu CLR z faktycznie wdrożonym plikiem DLL, zweryfikować listę referencji oraz wykonać kontrolne wywołanie funkcji na danych reprezentujących także przypadki graniczne.

W przypadku błędu po aktualizacji silnika należy odtworzyć zestaw w środowisku odpowiadającym docelowej wersji SQL Server i sprawdzić wszystkie zależności, a nie tylko główną bibliotekę. Pomocne jest ograniczenie kodu do klas dostępnych w .NET Framework obsługiwanym przez daną wersję SQL Server oraz unikanie zależności od interfejsów przeznaczonych wyłącznie dla aplikacji desktopowych lub usług systemu Windows. Jeżeli funkcja korzysta z plików, sieci albo kodu natywnego, trzeba osobno potwierdzić wymagany poziom dostępu i reguły zaufania. Taka weryfikacja pozwala odróżnić rzeczywistą niezgodność środowiska CLR od błędu logicznego w samej funkcji lub niepełnego wdrożenia zależnych zestawów.