This issue has been known since late last year, but there doesn't seem to be too much noise about it in the blogosphere. No doubt as we continue to create and consume more and more WCF services, troubleshooting configuration issues has become a common occurrence (can I get an amen?). Keep this in mind the next time you add a new service reference to your .Net projects.
Here's the scoop: when using a WCF proxy client object, simply having the typical Dispose() method fire off does not ensure the object is cleaned up. You see, Dispose() calls the Close() method, which actually makes a call across the wire to tell the remote service to do session clean-up before shutting down. We all know and respect the fallacies of distributed computing, right? Successfully disposing our client proxy involves a trip across the network (our particular situation here deals mainly with the two fallacies involving reliable networks and the whole latency thing). When the method call for session clean up to the server doesn't go as expected, Close() fires an exception and the client proxy is not disposed. When this happens, the Abort() method actually needs to be called in order to correctly clean up the object's state.
Correctly disposing the proxy object won't work if everything doesn't go well with the remote call during Close().
I found a couple good blog posts that discuss the issue in more detail with helpful solutions. Check them out:
http://www.iserviceoriented.com/blog/post/Indisposable+-+WCF+Gotcha+1.aspx
http://geekswithblogs.net/DavidBarrett/archive/2007/11/22/117058.aspx
Hopefully this knowledge will help prevent needless service debugging and troubleshooting as we try to quickly develop working software. So be mindful of the fact that we often need to pay special attention to how we use WCF client proxy objects.