Ładowanie niestandardowego modułu serwera proxy w .NET Framework

W aplikacji .NET Framework zarejestruj moduł serwera proxy w sekcji configuration/system.net/defaultProxy:

<defaultProxy>
  <module type="Company.Network.RoutingProxy, Company.Network" />
</defaultProxy>

Pierwsza nazwa to typ, a druga to tożsamość zestawu, a nie ścieżka DLL. Zestaw i zależności muszą być ładowane zgodnie ze zwykłymi regułami aplikacji.

Sprawdź dwie bramy. Po pierwsze, środowisko uruchomieniowe musi utworzyć publiczny typ implementujący IWebProxy przez konstruktor bez parametrów. Zachowaj wewnętrzne wyjątki z błędów ładowania lub tworzenia; poprzedzają one każde połączenie TCP przez proxy. W wersji desktop potwierdź, że rejestracja dotarła do wdrożonej konfiguracji pliku wykonywalnego. W przypadku ClickOnce porównaj zbudowany, opublikowany i zainstalowany plik .exe.config. Plik App.config biblioteki klas zwykle nie konfiguruje procesu hosta.

Po drugie, żądanie musi używać tego ustawienia domyślnego. Jawne przypisanie proxy może je zastąpić, a inny stos HTTP może nie odczytywać tego modelu konfiguracji. W module GetProxy i IsBypassed wymagają spójnych decyzji, a bezwzględny URI proxy musi używać właściwego schematu i portu.

Utrzymuj spójność zachowania poświadczeń. Getter tworzący zakodowane na stałe konto i ignorujący swój setter może zniweczyć późniejszą konfigurację nawet po udanym ładowaniu.

Jest to mechanizm konserwacyjny dla .NET Framework. W obecnym .NET używaj konfiguracji serwera proxy obsługiwanej przez klienta sieciowego, zamiast oczekiwać, że ta starsza rejestracja system.net będzie rządzić każdym HttpClient.