Cargar un módulo de proxy personalizado en .NET Framework
Compruebe la carga de tipos, la configuración del ejecutable y las anulaciones de solicitudes cuando un módulo defaultProxy parece no tener efecto.
Para una aplicación de .NET Framework, registre el módulo de proxy bajo configuration/system.net/defaultProxy:
<defaultProxy>
<module type="Company.Network.RoutingProxy, Company.Network" />
</defaultProxy>El primer nombre es el tipo y el segundo su identidad de ensamblado, no una ruta de DLL. El ensamblado y las dependencias deben cargarse según las reglas normales de la aplicación.
Compruebe dos puertas. Primero, el runtime debe construir un tipo público que implemente IWebProxy mediante un constructor sin parámetros. Conserve las excepciones internas de los fallos de carga o construcción; preceden a cualquier conexión TCP de proxy. Para una versión de escritorio, confirme que el registro llegó a la configuración desplegada del ejecutable. Con ClickOnce, compare el .exe.config compilado, publicado e instalado. El App.config de una biblioteca de clases normalmente no configura su proceso anfitrión.
Segundo, la solicitud debe usar ese valor predeterminado. Una asignación explícita de proxy puede reemplazarlo, y otra pila HTTP podría no leer este modelo de configuración. Dentro del módulo, GetProxy y IsBypassed necesitan decisiones coherentes, con un URI de proxy absoluto que use el esquema y el puerto correctos.
Haga coherente también el comportamiento de las credenciales. Un getter que fabrica una cuenta codificada e ignora su setter puede anular la configuración posterior incluso después de que la carga tenga éxito.
Este es un mecanismo de mantenimiento para .NET Framework. Use la configuración de proxy compatible con el cliente de red en .NET actual en lugar de esperar que este registro heredado de system.net gobierne cada HttpClient.