Getting a Custom Proxy Module Loaded in .NET Framework

For a .NET Framework application, register the proxy module beneath configuration/system.net/defaultProxy:

<defaultProxy>
  <module type="Company.Network.RoutingProxy, Company.Network" />
</defaultProxy>

The first name is the type and the second its assembly identity, not a DLL path. The assembly and dependencies must load through the application's normal rules.

Check two gates. First, the runtime must construct a public type implementing IWebProxy through a parameterless constructor. Keep inner exceptions from loading or construction failures; those precede any proxy TCP connection. For a desktop release, confirm the registration reached the executable's deployed configuration. With ClickOnce, compare the built, published and installed .exe.config. A class library's App.config does not ordinarily configure its host process.

Second, the request must use that default. An explicit proxy assignment can supersede it, and another HTTP stack may not read this configuration model. Inside the module, GetProxy and IsBypassed need consistent decisions, with an absolute proxy URI using the correct scheme and port.

Make credential behavior consistent too. A getter manufacturing a hardcoded account while ignoring its setter can defeat later configuration even after loading succeeds.

This is a maintenance mechanism for .NET Framework. Use the networking client's supported proxy configuration in current .NET rather than expecting this legacy system.net registration to govern every HttpClient.