My Development Blog

My Development experiences

WCF Services – Dispose can cause you problems

Posted by ipwright83 on November 7, 2013

Normally when you’re working with something that implements IDisposable you should always call Dispose() on it. Unfortunately there are a whole bunch of classes that implement IDisposable implicitly. What that means is that you don’t see Dispose in intelli-sense, which makes it quite difficult to check. The general rule is if it’s going to deal with Stream/Connections/GDI/Databases there will probably be a dispose in there somewhere. The simplest way to do this is to wrap the code in a using statement to ensure that Dispose is called even if there is an error.

Once such example of this is the WCFClient. You would normally expect to write something like the following

using(PaymentPortTypeClient client = new PaymentPortTypeClient())
    // Do Stuff

Unfortunately however for WCF the base class System.ServiceBase.ClientBase can throw an Exception in Dispose if the connection failed to open for any reason. This is a bit of a pain, so instead we need to conditionally dispose depending on the connection state.

A little helper for achieving this:

/// Use the service safely such that it will correctly dispose itself upon success or failure.
/// The delegate to execute safely 
public static void Use<T>(UseServiceDelegate codeBlock) 
   // Ensure that the factory has been initialized 
   IClientChannel proxy = (IClientChannel)channelFactory.CreateChannel(); 
   bool success = false; 
       success = true; 
       if (!success) 

At this point assuming you’ve placed the method in a class called Service you can use the following code to safely call the same code that Dispose would on your connection:

Service.Use<PaymentPortType>(proxy =>
   // Do Stuff

2 Responses to “WCF Services – Dispose can cause you problems”

  1. Would it be more maintainable just to call dispose in your new template and catch? Embedding implicit knowledge of internal behaviour is not ideal. What if Close or Abort didn’t dispose all resources in future. Could it also take a (by)ref of the class and null it. Then it’s reusable across more than just this one issue? The syntax would then resemble the original code more closely.

    • ipwright83 said

      Yeah – that probably makes more sense. I need to cite the original place I got the code example from – I just wanted to blog about it so I remembered it.

      In this case however, because the internal implementation is incorrect and highlights the problem, I think a deeper understanding of the internal behaviour is less of a problem than normal – where I’d consider it just plain wrong.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: