Jak zauważyłeś, System.Web
jest nieobsługiwaną biblioteką. Aby się odwołać System.Web
, musisz zadzwonić do CREATE ASSEMBLY
. Wygląda na to, że próbowałeś tego, ale jak odnalazłeś lokalizację System.Web.dll
? Czy skopiowałeś / wkleiłeś go w inne miejsce? SQL Server spróbuje zlokalizować zależne zestawy w tej samej lokalizacji. Innymi słowy, jeśli odwołujesz się do lokalizacji System.Web.dll
wszystkich pozostałych bibliotek zależnych mieszkających w tym samym katalogu, powinno działać dobrze. Oto działający przykład. Mogłem dodać zarówno System.Web
zestaw, jak i twój zestaw:
create assembly [System.Web]
from 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.Web.dll'
with permission_set = unsafe;
go
create assembly SystemWebTest
from 'c:\SqlServer\SystemWebTest.dll'
with permission_set = safe;
go
Możesz zobaczyć z komunikatów klienta wszystkie inne zestawy ładowane przez SQL Server. Pamiętaj jednak, że SQL Server wyświetla następujące ostrzeżenie dla każdego z nich:
rejestracja nie jest w pełni przetestowana w środowisku hostowanym SQL Server i nie jest obsługiwana. W przyszłości, jeśli uaktualnisz lub serwisujesz ten zestaw lub platformę .NET Framework, procedura integracji CLR może przestać działać. Więcej informacji można znaleźć w dokumentacji SQL Server Books Online.
Podobnie, ale dodając System.Web
, spójrz na następujące dodane zespoły:
select
name,
permission_set_desc,
is_visible
from sys.assemblies
where is_user_defined = 1
order by is_visible desc;
name permission_set_desc is_visible
System.Web UNSAFE_ACCESS 1
SystemWebTest SAFE_ACCESS 1
Microsoft.Build.Framework UNSAFE_ACCESS 0
System.Xaml UNSAFE_ACCESS 0
System.ComponentModel.DataAnnotations UNSAFE_ACCESS 0
System.Runtime.Caching UNSAFE_ACCESS 0
System.Web.ApplicationServices UNSAFE_ACCESS 0
System.Drawing UNSAFE_ACCESS 0
Microsoft.Build.Utilities.v4.0 UNSAFE_ACCESS 0
System.DirectoryServices UNSAFE_ACCESS 0
System.DirectoryServices.Protocols UNSAFE_ACCESS 0
System.EnterpriseServices UNSAFE_ACCESS 0
System.Runtime.Remoting UNSAFE_ACCESS 0
System.Runtime.Serialization.Formatters.Soap UNSAFE_ACCESS 0
System.Design UNSAFE_ACCESS 0
System.Windows.Forms UNSAFE_ACCESS 0
Accessibility UNSAFE_ACCESS 0
System.Drawing.Design UNSAFE_ACCESS 0
System.Web.RegularExpressions UNSAFE_ACCESS 0
Microsoft.Build.Tasks.v4.0 UNSAFE_ACCESS 0
System.ServiceProcess UNSAFE_ACCESS 0
System.Configuration.Install UNSAFE_ACCESS 0
System.Runtime.Serialization UNSAFE_ACCESS 0
System.ServiceModel.Internals UNSAFE_ACCESS 0
SMDiagnostics UNSAFE_ACCESS 0
Warto pamiętać o tym, co faktycznie się tutaj dzieje, i chociaż inne dodatkowe zestawy nie mają możliwości uzyskania punktów wejścia T-SQL, są one teraz zależne. Zastanowiłbym się nad opcjami, aby zobaczyć, czy naprawdę potrzebujesz odniesieniaSystem.Web
, czy też istnieje inna droga do osiągnięcia tego, co chcesz.
System.Web
nie ma na liście „Obsługiwane biblioteki”, do której prowadzisz link: nie gwarantuje się, że będzie działał! . Możesz napotkać sytuacje, szczególnie w przypadku zestawów znaków ASCII spoza USA, które nie zachowują się zgodnie z oczekiwaniami, a Microsoft nie naprawi tego. Dodam notatkę na ten temat w mojej odpowiedzi, aby było jasne dla tych, którzy mogą nie wiedzieć.Sprawdź tę odpowiedź . Nie musisz używać
Uri.UnescapeDataString
lubSystem.Web
. Istnieje klasa wywoływanaWebUtility
wewnątrzSystem.Net
z funkcjamiHtmlEncode
iHtmlDecode
.źródło
WebUtility
jest dostępny tylko dla osób korzystających z SQL Server 2012, 2014 lub nowszych. Ci, którzy nadal korzystają z SQL Server 2005, 2008 i 2008 R2, nie będą mogli tego użyć, ponieważ został wprowadzony w .NET Framework 4.0.