Завантаження користувацького модуля проксі в .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.