Caricare un modulo proxy personalizzato in .NET Framework
Controllare il caricamento dei tipi, la configurazione dell'eseguibile e le sostituzioni delle richieste quando un modulo defaultProxy sembra non avere effetto.
Per un'applicazione .NET Framework, registrare il modulo proxy sotto configuration/system.net/defaultProxy:
<defaultProxy>
<module type="Company.Network.RoutingProxy, Company.Network" />
</defaultProxy>Il primo nome è il tipo e il secondo la sua identità di assembly, non un percorso DLL. L'assembly e le dipendenze devono essere caricati secondo le normali regole dell'applicazione.
Controllare due cancelli. Innanzitutto, il runtime deve costruire un tipo pubblico che implementi IWebProxy tramite un costruttore senza parametri. Conservare le eccezioni interne da errori di caricamento o costruzione; precedono qualsiasi connessione TCP proxy. Per una versione desktop, confermare che la registrazione abbia raggiunto la configurazione distribuita dell'eseguibile. Con ClickOnce, confrontare il .exe.config compilato, pubblicato e installato. L'App.config di una libreria di classi normalmente non configura il suo processo host.
In secondo luogo, la richiesta deve usare tale impostazione predefinita. Un'assegnazione esplicita del proxy può sostituirla, e un altro stack HTTP potrebbe non leggere questo modello di configurazione. All'interno del modulo, GetProxy e IsBypassed richiedono decisioni coerenti, con un URI proxy assoluto che usa lo schema e la porta corretti.
Rendere coerente anche il comportamento delle credenziali. Un getter che crea un account codificato e ignora il suo setter può vanificare una configurazione successiva anche dopo un caricamento riuscito.
Questo è un meccanismo di manutenzione per .NET Framework. Usare la configurazione proxy supportata dal client di rete in .NET attuale invece di aspettarsi che questa registrazione system.net legacy governi ogni HttpClient.