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