Proxy modulu pertsonalizatu bat .NET Framework-en kargatzea
Egiaztatu moten karga, exekutagarriaren konfigurazioa eta eskaeren gainidazketak defaultProxy moduluak eraginik ez duela dirudienean.
.NET Framework aplikazio baterako, erregistratu proxy modulua configuration/system.net/defaultProxy azpian:
<defaultProxy>
<module type="Company.Network.RoutingProxy, Company.Network" />
</defaultProxy>Lehenengo izena mota da eta bigarrena bere assembly-identitatea, ez DLL bide bat. Assembly-a eta mendekotasunak aplikazioaren ohiko arauen arabera kargatu behar dira.
Egiaztatu bi ate. Lehenik, runtime-ak IWebProxy inplementatzen duen mota publiko bat eraiki behar du parametrorik gabeko konstruktore baten bidez. Mantendu karga- edo eraikitze-hutsegiteen barne-salbuspenak; proxy TCP konexioaren aurretik datoz. Mahaigaineko bertsio baterako, berretsi erregistroa exekutagarriaren inplementatutako konfiguraziora iritsi dela. ClickOnce-rekin, alderatu eraikitako, argitaratutako eta instalatutako .exe.config fitxategia. Klase-liburutegi baten App.config-ek normalean ez du bere ostalari-prozesua konfiguratzen.
Bigarrenik, eskaerak lehenetsi hori erabili behar du. Proxy esleipen esplizitu batek ordezkatu dezake, eta beste HTTP pila batek agian ez du konfigurazio-eredu hau irakurriko. Moduluaren barruan, GetProxy eta IsBypassed erabaki koherenteak behar dituzte, eskema eta portu zuzena erabiltzen dituen proxy URI absolutu batekin.
Egin kredentzialen portaera koherente ere. Kontu gogor kodetua sortzen duen getter batek eta bere setterra alde batera uzten badu, geroagoko konfigurazioa zapuztu dezake kargak arrakasta izan ondoren ere.
Hau .NET Framework-erako mantentze-mekanismo bat da. Erabili sare-klienteak onartzen duen proxy konfigurazioa uneko .NET-en, system.net erregistro zaharkitu honek HttpClient guztiak gobernatuko dituela espero beharrean.