Click here to Skip to main content
13,045,790 members (48,340 online)
Click here to Skip to main content
Add your own
alternative version

Tagged as


9 bookmarked
Posted 19 Apr 2010

The Proper Use and Disposal of WCF Channels (or CommunicationObjectFaultedException ?!*#*$)

, 20 Apr 2010
Rate this:
Please Sign up or sign in to vote.
In this post, I explore the subtle but disastrous consequences of expecting a 'using' block to clean up your WCF channels.

In this post, I explore the subtle but disastrous consequences of expecting a using block to clean up your WCF channels.

NOTE: The examples show the use of a generated proxy but the issue and solution applies to all ICommunicationObject including generated proxies (ClientBase<T>) as well as ChannelFactory and ChannelFactory<T>.

Many sleepless nights have been spent wondering why, regardless of any exception handling, the following code throws a CommunicationObjectFaultedException when .HelloWorld() throws, even though the exception is being swallowed.

Typical 'using' Disposal Pattern

using (WCFServiceClient c = new WCFServiceClient())
    catch (Exception ex)
        // handle the exception

Consider that when an exception occurs during the use of a channel, it enters the Faulted state and, in this Faulted state, calling .Close() will throw a CommunicationObjectFaultedException.

The using statement, as you know, ensures that .Dispose() is called before the using block is closed. For channels, which typically have private .Dispose() methods, .Dispose() simply calls .Close(). Aha! Are you picking up what I am putting down?

The trap of the typical using disposal pattern illustrated:

using (WCFServiceClient c = new WCFServiceClient())
    catch (Exception ex)
        // You don't know it yet but your mellow has just been harshed.

        // If you handle this exception and fall through you will 
        // still be cheerfully greeted with an unhandled 
        // CommunicationObjectFaultedException when 'using' tries to .Close() the client.

        // If you throw or re-throw from here you will never see that exception, 
        // it is gone forever. 
        // buh bye.
        // All you will get is an unhandled CommunicationObjectFaultedException
} // <-- here is where the CommunicationObjectFaultedException is thrown

The solution to this problem is to ensure that the channel can successfully transition to the Closed state upon closure of the using block. This is done by acknowledging the Faulted state by calling .Abort() from within your catch, which actually does close the channel albeit abruptly. Any subsequent .Close() is a NOOP.

A proper using disposal pattern

using (WCFServiceClient client = new WCFServiceClient())
    catch (Exception ex)
        // acknowledge the Faulted state and transition to Closed

        // handle the exception or rethrow, makes no nevermind to me, my
        // yob is done ;-D

There are some scenarios where the shape of your surrounding code does not lend itself to using a using block.

While the using block does have its benefits, such as the scoping provided by the block, in the context of a channel all it does is call .Close() and we can do that easily enough.

Proper use of a channel without using

WCFServiceClient c = new WCFServiceClient();

    // acknowledge the Faulted state and transition to Closed

    // handle or throw

There you have it, my take on the proper use and disposal of WCF channels.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Sky Sanders
Software Developer (Senior) Salient Solutions
United States United States
My name is Sky Sanders and I am an end-to-end, front-to-back software solutions architect with more than 20 years experience in IT infrastructure and software development, the last 10 years being focused primarily on the Microsoft .NET platform.

My motto is 'I solve problems.' and I am currently available for hire.

I can be contacted at

You may also be interested in...


Comments and Discussions

GeneralWCFServiceClient Pin
BMWABCD24-Sep-10 6:52
memberBMWABCD24-Sep-10 6:52 
GeneralRe: WCFServiceClient Pin
Sky Sanders24-Sep-10 7:13
memberSky Sanders24-Sep-10 7:13 
GeneralMore reference Pin
Sky Sanders21-Apr-10 11:09
memberSky Sanders21-Apr-10 11:09 
GeneralRe: More reference Pin
Mihail-Florin Popa29-Dec-14 4:56
memberMihail-Florin Popa29-Dec-14 4:56 
GeneralRe: More reference Pin
Thomas Eyde19-Jan-15 1:38
memberThomas Eyde19-Jan-15 1:38 
GeneralI propose some extensions for your team to use Pin
cmartinbot21-Apr-10 5:51
membercmartinbot21-Apr-10 5:51 
GeneralRe: I propose some extensions for your team to use Pin
Sky Sanders21-Apr-10 7:10
memberSky Sanders21-Apr-10 7:10 
Thanks for that. It is a nice pattern.

Previously I have worked on something similar with a bit more functionality, here[^], (skip past my top entry to the "More Bad" entry) and it is also a good pattern but I felt that it might unnecessarily complicate the explanation.

Your pattern is a nice middle ground and a good contribution to this post.

Thanks. (+5)
QuestionProbably also applicable to SQL connections and other things? Pin
supercat920-Apr-10 5:55
membersupercat920-Apr-10 5:55 
AnswerRe: Probably also applicable to SQL connections and other things? Pin
RalfKoch20-Apr-10 6:08
memberRalfKoch20-Apr-10 6:08 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.170713.1 | Last Updated 20 Apr 2010
Article Copyright 2010 by Sky Sanders
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid