Laai 'n pasgemaakte proxy-module in .NET Framework
Kontroleer tipe-lading, konfigurasie van die uitvoerbare lêer en versoekoorwegings wanneer 'n defaultProxy-module geen effek blyk te hê nie.
Vir 'n .NET Framework-toepassing, registreer die proxy-module onder configuration/system.net/defaultProxy:
<defaultProxy>
<module type="Company.Network.RoutingProxy, Company.Network" />
</defaultProxy>Die eerste naam is die tipe en die tweede die assembly-identiteit, nie 'n DLL-pad nie. Die assembly en afhanklikhede moet volgens die toepassing se normale reëls laai.
Kontroleer twee hekke. Eerstens moet die runtime 'n openbare tipe bou wat IWebProxy deur 'n parameterlose konstruktor implementeer. Behou interne uitsonderings van laai- of konstruksiefoute; dié kom voor enige proxy-TCP-verbinding. Vir 'n lessenaaruitgawe, bevestig dat die registrasie die ontplooide konfigurasie van die uitvoerbare lêer bereik het. Met ClickOnce, vergelyk die geboude, gepubliseerde en geïnstalleerde .exe.config. 'n Klasbiblioteek se App.config konfigureer gewoonlik nie sy gasheerproses nie.
Tweedens moet die versoek daardie verstek gebruik. 'n Eksplisiete proxy-toewysing kan dit vervang, en 'n ander HTTP-stapel lees moontlik nie hierdie konfigurasiemodel nie. Binne die module het GetProxy en IsBypassed konsekwente besluite nodig, met 'n absolute proxy-URI wat die korrekte skema en poort gebruik.
Maak die gedrag van geloofsbriewe ook konsekwent. 'n Getter wat 'n hardgekodeerde rekening skep en sy setter ignoreer, kan latere konfigurasie verydel selfs nadat die lading geslaag het.
Dit is 'n instandhoudingsmeganisme vir .NET Framework. Gebruik die netwerkklient se ondersteunde proxy-konfigurasie in huidige .NET eerder as om te verwag dat hierdie ou system.net-registrasie elke HttpClient sal beheer.