Charger un module de proxy personnalisé dans .NET Framework
Vérifiez le chargement des types, la configuration de l'exécutable et les substitutions de requêtes lorsqu'un module defaultProxy semble sans effet.
Pour une application .NET Framework, enregistrez le module de proxy sous configuration/system.net/defaultProxy :
<defaultProxy>
<module type="Company.Network.RoutingProxy, Company.Network" />
</defaultProxy>Le premier nom est le type et le second son identité d'assembly, pas un chemin de DLL. L'assembly et ses dépendances doivent se charger selon les règles normales de l'application.
Vérifiez deux portes. Premièrement, le runtime doit construire un type public implémentant IWebProxy via un constructeur sans paramètre. Conservez les exceptions internes des échecs de chargement ou de construction ; elles précèdent toute connexion TCP de proxy. Pour une version de bureau, confirmez que l'enregistrement a atteint la configuration déployée de l'exécutable. Avec ClickOnce, comparez le .exe.config compilé, publié et installé. L'App.config d'une bibliothèque de classes ne configure généralement pas son processus hôte.
Deuxièmement, la requête doit utiliser cette valeur par défaut. Une affectation explicite de proxy peut la remplacer, et une autre pile HTTP peut ne pas lire ce modèle de configuration. Dans le module, GetProxy et IsBypassed doivent prendre des décisions cohérentes, avec un URI de proxy absolu utilisant le bon schéma et le bon port.
Rendez aussi le comportement des informations d'identification cohérent. Un getter qui fabrique un compte codé en dur tout en ignorant son setter peut ruiner une configuration ultérieure même après un chargement réussi.
Il s'agit d'un mécanisme de maintenance pour .NET Framework. Utilisez la configuration de proxy prise en charge par le client réseau dans .NET actuel plutôt que de compter sur cet enregistrement system.net hérité pour régir chaque HttpClient.