A few weeks ago I was presenting a code sample that I created last year and discovered a mysterious problem.

First, let me explain the sample. It is a proxy wrapper for WCF clients that illustrates how to swallow timeout exceptions and recreate channels automatically when there is an exception that faults the channel. The idea is this:

• When a channel with a transport session times out, does the user need to see an error? Not really. But, the exception won't show up until you try to call the service, so my wrapper catches communication exceptions and if they are not faults it creates a new channel and retries the same call to the service once more. The theory is, if it fails again, we probably have a bigger problem. Otherwise, we will have successfully allowed the client to continue working without seeing an error.
• When an uncaught exception from the service faults the channel, the client channel will also be faulted if the call is not one-way. The user should see the error message, even if it is an uncaught exception, but the next time they use the proxy they should get a new channel so they can continue to work. So, the proxy wrapper creates the channel again if the channel is faulted, before making the next call.

I explained this in my ASP.NET Pro article on the subject. The latest code for this is here: http://www.dasblonde.net/downloads/Proxies.zip

Well, the problem that In encountered is that all of a sudden my logic for checking if the channel was faulted after a timeout, was failing!!!! It was strange - from one stack frame to another, the channel went from Faulted to Created. But none of my code affected that change! So, of course I thought that something had changed in .NET 3.5 related to channel factory caching that might have had a side-effect of my code...and I didn't have time to investigate further until today while I was talking with my colleague Brian Noyes about the subject.

Long story short, he ran the code, reproduced the problem, and remembered that there were some strange behaviors with SUO files for a solution that could cause this. He deleted the SUO and then the sample worked like it originally did!!!!! I did the same, and found the same result.

This is really messed up! Apparently this is a common problem, but I have never heard about it before. The real annoyance is the time I spent troubleshooting this before I talked to Brian, and the doubts it put in my mind about new features of WCF and possible regressions....and yet I was wrong...it was the stupid SUO file. What the? Holy? This is an unacceptable bug. Who knows what kind of misleading issues this could cause developers in their day-to-day work.