Загрузка ўласнага проксі-модуля ў .NET Framework

Для праграмы .NET Framework зарэгіструйце проксі-модуль пад configuration/system.net/defaultProxy:

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

Першае імя — гэта тып, а другое — ідэнтычнасць зборкі, а не шлях да DLL. Зборка і залежнасці павінны загружацца па звычайных правілах праграмы.

Праверце дзве брамы. Па-першае, асяроддзе выканання павінна стварыць публічны тып, які рэалізуе IWebProxy праз канструктар без параметраў. Захоўвайце ўнутраныя выключэнні ад збояў загрузкі або стварэння; яны папярэднічаюць любому TCP-злучэнню праз проксі. Для настольнага выпуску пераканайцеся, што рэгістрацыя дайшла да разгорнутай канфігурацыі выканальнага файла. З ClickOnce параўнайце сабраны, апублікаваны і ўсталяваны .exe.config. App.config бібліятэкі класаў звычайна не канфігуруе працэс-гаспадар.

Па-другое, запыт павінен выкарыстоўваць гэтыя defaults. Яўнае прызначэнне проксі можа замяніць іх, а іншы HTTP-стэк можа не чытаць гэтую мадэль канфігурацыі. Унутры модуля GetProxy і IsBypassed патрабуюць узгодненых рашэнняў, з абсалютным URI проксі, які выкарыстоўвае правільную схему і порт.

Зрабіце паводзіны ўліковых даных узгодненымі. Гетэр, які стварае жорстка закадзіраваны ўліковы запіс і ігнаруе свой сэтэр, можа знішчыць наступную канфігурацыю нават пасля паспяховай загрузкі.

Гэта механізм абслугоўвання для .NET Framework. Выкарыстоўвайце падтрымліваную канфігурацыю проксі сеткавага кліента ў сучасным .NET, а не спадзявайцеся, што гэтая састарэлая рэгістрацыя system.net будзе кіраваць кожным HttpClient.