Для приложения .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.

Похожие статьи