Ein benutzerdefiniertes Proxy-Modul in .NET Framework laden
Prüfen Sie Typenladung, Konfiguration der ausführbaren Datei und Anforderungsüberschreibungen, wenn ein defaultProxy-Modul wirkungslos erscheint.
Für eine .NET Framework-Anwendung registrieren Sie das Proxy-Modul unter configuration/system.net/defaultProxy:
<defaultProxy>
<module type="Company.Network.RoutingProxy, Company.Network" />
</defaultProxy>Der erste Name ist der Typ, der zweite die Assembly-Identität, kein DLL-Pfad. Assembly und Abhängigkeiten müssen nach den normalen Regeln der Anwendung geladen werden.
Prüfen Sie zwei Tore. Erstens muss die Runtime einen öffentlichen Typ erzeugen, der IWebProxy über einen parameterlosen Konstruktor implementiert. Behalten Sie innere Ausnahmen aus Lade- oder Konstruktionsfehlern; sie gehen jeder Proxy-TCP-Verbindung voraus. Bei einer Desktop-Version bestätigen Sie, dass die Registrierung die bereitgestellte Konfiguration der ausführbaren Datei erreicht hat. Bei ClickOnce vergleichen Sie die erstellte, veröffentlichte und installierte .exe.config. Die App.config einer Klassenbibliothek konfiguriert normalerweise nicht ihren Hostprozess.
Zweitens muss die Anforderung diesen Standard verwenden. Eine explizite Proxy-Zuweisung kann ihn außer Kraft setzen, und ein anderer HTTP-Stack liest dieses Konfigurationsmodell möglicherweise nicht. Innerhalb des Moduls benötigen GetProxy und IsBypassed konsistente Entscheidungen, mit einer absoluten Proxy-URI, die das richtige Schema und den richtigen Port verwendet.
Halten Sie auch das Anmeldeinformationsverhalten konsistent. Ein Getter, der ein fest codiertes Konto erzeugt und seinen Setter ignoriert, kann eine spätere Konfiguration zunichtemachen, selbst nachdem das Laden erfolgreich war.
Dies ist ein Wartungsmechanismus für .NET Framework. Verwenden Sie in aktuellem .NET die unterstützte Proxykonfiguration des Netzwerkclients, statt zu erwarten, dass diese Legacy-system.net-Registrierung jedes HttpClient steuert.