Carregar um módulo de proxy personalizado no .NET Framework
Verifique o carregamento de tipos, a configuração do executável e as substituições de solicitações quando um módulo defaultProxy parece não ter efeito.
Para uma aplicação .NET Framework, registre o módulo de proxy sob configuration/system.net/defaultProxy:
<defaultProxy>
<module type="Company.Network.RoutingProxy, Company.Network" />
</defaultProxy>O primeiro nome é o tipo e o segundo é a identidade do assembly, não um caminho de DLL. O assembly e as dependências devem ser carregados segundo as regras normais da aplicação.
Verifique dois portões. Primeiro, o runtime deve construir um tipo público que implemente IWebProxy por meio de um construtor sem parâmetros. Preserve as exceções internas de falhas de carregamento ou construção; elas precedem qualquer conexão TCP de proxy. Para uma versão desktop, confirme que o registro chegou à configuração implantada do executável. Com ClickOnce, compare o .exe.config compilado, publicado e instalado. O App.config de uma biblioteca de classes normalmente não configura seu processo host.
Segundo, a solicitação deve usar esse padrão. Uma atribuição explícita de proxy pode substituí-lo, e outra pilha HTTP pode não ler este modelo de configuração. Dentro do módulo, GetProxy e IsBypassed precisam de decisões consistentes, com um URI de proxy absoluto usando o esquema e a porta corretos.
Mantenha também o comportamento das credenciais consistente. Um getter que fabrica uma conta codificada e ignora seu setter pode anular a configuração posterior mesmo após o carregamento bem-sucedido.
Este é um mecanismo de manutenção para .NET Framework. Use a configuração de proxy suportada pelo cliente de rede no .NET atual em vez de esperar que este registro legado de system.net governe cada HttpClient.