31

We are using WCF service

on the client side we are planning to explicitly close the connection It seems there are more then one way of closing

Sample1: In the finally block of the WCF service consumption use

if (client.State == CommunicationState.Faulted)
{
  client.Abort();
}
client.Close();

Since if the service is in fault state we will not be able to call close()

Sample2:

using(ClientProxy proxy = new ClientProxy())
{   
  //call your service methods
}

in sample2 i am not sure what will happen if the service is in fault state, will it throw error closing the connection?

Harry Johnston
  • 35,639
  • 6
  • 68
  • 158
Balaji
  • 2,109
  • 5
  • 27
  • 34
  • @Balaji- take a look at this post- http://stackoverflow.com/questions/573872/what-is-the-best-workaround-for-the-wcf-client-using-block-issue . It is most helpful – RichardOD Sep 18 '09 at 10:11

4 Answers4

37

You have all the necessary information at hand - the resulting Best Practice to use and properly close/abort all your WCF client proxies would be:

YourClientProxy clientProxy = new YourClientProxy();

try
{
   .. use your service
   clientProxy.Close();
}
catch(FaultException)
{
   clientProxy.Abort();
}
catch(CommunicationException)
{
   clientProxy.Abort();
}
catch (TimeoutException)
{ 
   clientProxy.Abort();
}

Catching the FaultException handles all cases when the service responsded with an error condition (and thus your channel is in a faulted state), and CommunicationException will handle all other communication-related exceptions that can occur, like network connectivity dropping etc.

The approach with the using() block won't work, since if an exception happens at the end of the block, when the Dispose() method calls the Close() method on the client proxy, you have no way to catching and handling that.

Luke Girvin
  • 13,221
  • 9
  • 64
  • 84
marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
  • Thanks to all for the reply. I wish there was some settings in the web.config file to take care of the connection closing! – Balaji Sep 09 '09 at 15:35
  • 1
    FaultException is CommunicationException, so technically you don't need both catch clauses (unless you plan on handling the two cases differently). – bobbymcr Sep 09 '09 at 20:29
  • FaultException is a descendant of CommunicationException, and you're right - just handling CommunicationException would be ok, as long as you don't need to somehow do different things for the two different cases. Guess it's just a habit of mine to list the most commonly occuring exception types separately, even if I don't do anything special in either of them..... – marc_s Sep 09 '09 at 20:34
  • @BrentArias: please don't add such a huge statement of yours to my answer - if you have something to say in addition, you can always add an answer of your own to further explain what I've been saying. THanks. – marc_s Sep 26 '14 at 05:51
19

The 2nd sample using the "using" block is incorrect. The using block ensures that the Dispose method is called on the proxy object. The Dispose method in turn calls the Close method which will (try to) connect to the service which will throw an exception when the communication state is faulted. So your feelings/hunch are absolutely right. It would be nice if the proxy Dispose method used the code from your first sample but it doesn't so don't use the using block :)

Manfred
  • 5,320
  • 3
  • 35
  • 29
olle
  • 4,597
  • 24
  • 28
4

In Juval Lowy's Excellent Programming WCF book he recommends:

try 
{
    ClientProxy clientProxy = new ClientProxy();
    clientProxy.SomeMethod();
    clientProxy.Close();
}
catch
{
    proxy.Abort();
}
RichardOD
  • 28,883
  • 9
  • 61
  • 81
  • 2
    Ha .. I saw that code in the book, but I think it doesn't compile. The service must be declared outside of the try block to be accessed in the catch block... and then you probably want to put a null check around it. – foson Apr 01 '11 at 20:25
  • @foson- do you know which page it was on? You are right about the above code. I have the book but read it a while back now. – RichardOD Jan 31 '12 at 20:04
2

Use sample 1

Here is a good article on why you should not use using:

http://msdn.microsoft.com/en-us/library/aa355056.aspx

Shiraz Bhaiji
  • 64,065
  • 34
  • 143
  • 252