Dispose a Web Service Proxy class?

Question

When you create and use a Web Service proxy class in the ASP.Net framework, the class ultimately inherits from Component, which implements IDisposable.

I have never seen one example online where people dispose of a web proxy class, but was wondering if it really needs to be done. When I call only one method, I normally wrap it in a using statement, but if I have a need to call it several times throughout the page, I might end up using the same instance, and just wondered what the ramifications are of not disposing it.

Answer 1

You need to dispose everything that implements IDisposable.

The implementation of IDisposable signifies that the object holds onto something that the garbage collector doesn't intrinsically track - might be a connection, might be a file, might be some other handle - or might be nothing at all, it doesn't really matter. You shouldn't concern yourself with the implementation details because those are subject to change.

The class may or may not truly use unmanaged resources. It may or may not have a finalizer. It makes little difference; if the class implements IDisposable, then it's asking you to Dispose it when you're done. Even if the Dispose method does nothing, you never know when somebody will replace the reference to that class with a reference to a subclass that really does need to be disposed.

Answer 2

The short answer is that with Web Service Proxy Classes, you should Close them and not Dispose them.

In almost every case you should dispose of things that implement IDisposable. However, Web Service Proxy classes are a special case. With these classes, and all classes that inherit from System.ServiceModel.ClientBase, it is a best practice to not call dispose but to call the Close method directly.

Using reflector, you can see that the Dispose method of ClientBase simply calls Close. So if there are no exceptions, Dispose and Close will do the same thing. However if there is an exception, there will be different behaviors.

Because the Close method can throw exceptions, you should call it directly and catch it's exception. If you call the Dispose method, you should also catch the exceptions, but your code will be harder to understand.

This also means that you should avoid putting the declaration of the proxy in a using statement. In this case, if an exception is thrown in the using block, it will be obscured. The Dispose call that is auto generated by the using block will get called because it is in a finally block. The exception that is thrown from the Close in the Dispose will obscure whatever exception was previously thrown.

To see more detailed explinations, read these articles on MSDN, Coding Up Style, BlogginAbout.Net, and StackOverflow.

For the backstory on why it is implemented this way, check on this thread on the MSDN forums.

Answer 3

Sometimes Dispose() is just a dummy (inherited from a base class), but then it is still a good practice to call it, to be safe for future changes.

A WebService/WCF proxy is holding a connection, so it is certainly a good idea to call Dispose() or Close(). Doing so inside a using block is of course preferable since it is exception safe.

But in your case (using the proxy in multiple methods on your page) the use of multiple using blocks probably would take a performance hit. It is OK to replace the using blocks with a call Close() in an event that comes late in the page cycle. I'm not sure about ASP.NET best practices here, but I would use OnPreRender or OnPageUnload or something.

You will loose exception safety here but that is not a fundamental problem, the GC will solve that.

Answer 4

IMHO, there's nothing like disposing a web-service proxy class.

Most of the proxies are:

• Stateless, as such calling using one instance or using multiple instances does not make any difference
• Intermittent meaning that they close the connection as soon as all response is processed