In oanpast proxy-module lade yn .NET Framework
Kontrolearje type-lading, konfiguraasje fan it útfierbere bestân en oerskriuwings fan oanfragen as in defaultProxy-module gjin effekt liket te hawwen.
Foar in .NET Framework-applikaasje registrearje jo de proxy-module ûnder configuration/system.net/defaultProxy:
<defaultProxy>
<module type="Company.Network.RoutingProxy, Company.Network" />
</defaultProxy>De earste namme is it type en de twadde de assembly-identiteit, net in DLL-paad. De assembly en ôfhinklikheden moatte lade neffens de normale regels fan de applikaasje.
Kontrolearje twa poarten. Earst moat de runtime in iepenbier type bouwe dat IWebProxy ymplemintearret fia in parameterleaze konstruktor. Behâld ynderlike útsûnderingen fan laad- of boutflaters; dy komme foar elke proxy-TCP-ferbining. Foar in desktop-útjefte befêstigje jo dat de registraasje de útrôle konfiguraasje fan it útfierbere bestân berikt hat. Mei ClickOnce fergelykje de boud, publisearre en ynstallearre .exe.config. De App.config fan in klassebibleteek konfigurearret normaal net syn hostproses.
Twad, it fersyk moat dy standert brûke. In eksplisite proxy-tawizing kin it ferfange, en in oare HTTP-stack lêst dit konfiguraasjemodel miskien net. Yn 'e module hawwe GetProxy en IsBypassed konsistinte besluten nedich, mei in absolute proxy-URI dy't it juste skema en de juste poarte brûkt.
Meitsje ek it gedrach fan oanmeldgegevens konsistint. In getter dy't in hardkodeare akkount makket en syn setter negearret, kin lettere konfiguraasje ferrinnewearje, sels nei suksesfol laden.
Dit is in ûnderhâldsmeganisme foar .NET Framework. Brûk de proxy-konfiguraasje dy't de netwurkklient stipet yn aktueel .NET, ynstee fan te ferwachtsjen dat dizze ferâldere system.net-registraasje elke HttpClient bestjoert.