Зареждане на персонализиран прокси модул в .NET Framework
Проверете зареждането на типове, конфигурацията на изпълнимия файл и отменянето на заявки, когато модулът defaultProxy изглежда без ефект.
За приложение на .NET Framework регистрирайте прокси модула под configuration/system.net/defaultProxy:
<defaultProxy>
<module type="Company.Network.RoutingProxy, Company.Network" />
</defaultProxy>Първото име е типът, а второто — идентичността на сборката, а не път до DLL. Сборката и зависимостите трябва да се зареждат по обичайните правила на приложението.
Проверете две врати. Първо, средата за изпълнение трябва да създаде публичен тип, реализиращ IWebProxy, чрез конструктор без параметри. Запазвайте вътрешните изключения от грешки при зареждане или създаване; те предхождат всяка TCP връзка през прокси. За настолна версия потвърдете, че регистрацията е достигнала разположената конфигурация на изпълнимия файл. С ClickOnce сравнете създадения, публикувания и инсталирания .exe.config. App.config на библиотека с класове обикновено не конфигурира процеса-домакин.
Второ, заявката трябва да използва тази настройка по подразбиране. Явното задаване на прокси може да я замести, а друг HTTP стек може да не чете този модел на конфигурация. Вътре в модула GetProxy и IsBypassed изискват последователни решения, с абсолютен URI на прокси, използващ правилната схема и порт.
Направете и поведението на идентификационните данни последователно. Гетър, който създава твърдо зададен акаунт и игнорира своя сетер, може да провали последваща конфигурация дори след успешно зареждане.
Това е механизъм за поддръжка на .NET Framework. Използвайте поддържаната от мрежовия клиент конфигурация на прокси в текущия .NET, вместо да очаквате тази наследена регистрация system.net да управлява всеки HttpClient.