Today I was helping one of the members of a team I am working with diagnose and resolve some issues with a misbehaving proxy server. I'm happy to report that we were able to confirm that the proxy server in-between us and the web-service was the problem and we were able to route around the problem using an alternative proxy. However - thats not what I wanted to talk about.
During the course of the debugging session we needed to flick the use of the proxy server on and off - now I knew by default that the proxy server was not being used by the SoapHttpClientProtocol-derived surrogate, and I knew that I could tell it to use a specific proxy by creating an instance of WebProxy and assigning it to the Proxy property - but instead of going to the effort of cutting and pasting the URL to the proxy server out of the IE configuration screens I "assumed" that .NET would have a super neat way of doing it.
surrogate.Proxy = WebProxy.GetDefaultProxy();
OK, is this blog worthy? Probably not, but what is blog worthy is that the framework is so well built that once you get inside the framework you can start to feel where you are going. The funny thing is that I guess that that method would exist and confirmed with with Intellisense so quickly that I doubt that Emily (who I was working with) even noticed that I had never used that method before :P (correct me in my comments if I am incorrect Emily).