Vista - WCF: Why is the client's IDisposeable implementation private?

Why is the IDisposeable implementation of WCF clients private?

I'm glad that you can still Dispose() by casting or with using ( .. ) { .. }
because IDisposable is indeed implemented but what was the design reasoning
to make Dispose() private?

Jon

* Jon Davis wrote, On 21-5-2007 23:59:
> Why is the IDisposeable implementation of WCF clients private?
>
> I'm glad that you can still Dispose() by casting or with using ( .. ) { .. }
> because IDisposable is indeed implemented but what was the design reasoning
> to make Dispose() private?
>
> Jon
>
>

This is usually done when there is a Close, End or Finish function,
which will call Dispose for you.

Jesse

"Jesse Houwing" <jesse.houwing@nospam-sogeti.nl> wrote in message
news:u$Bn5m$mHHA.2452@TK2MSFTNGP04.phx.gbl...
>* Jon Davis wrote, On 21-5-2007 23:59:
>> Why is the IDisposeable implementation of WCF clients private?
>>
>> I'm glad that you can still Dispose() by casting or with using ( .. ) {
>> .. } because IDisposable is indeed implemented but what was the design
>> reasoning to make Dispose() private?
>
> This is usually done when there is a Close, End or Finish function, which
> will call Dispose for you.

I had thought the reverse, that Dispose() would perform closures, as with
using 'using' with Stream objects.

Jon

* Jon Davis wrote, On 22-5-2007 0:51:
> "Jesse Houwing" <jesse.houwing@nospam-sogeti.nl> wrote in message
> news:u$Bn5m$mHHA.2452@TK2MSFTNGP04.phx.gbl...
>> * Jon Davis wrote, On 21-5-2007 23:59:
>>> Why is the IDisposeable implementation of WCF clients private?
>>>
>>> I'm glad that you can still Dispose() by casting or with using ( .. ) {
>>> .. } because IDisposable is indeed implemented but what was the design
>>> reasoning to make Dispose() private?
>> This is usually done when there is a Close, End or Finish function, which
>> will call Dispose for you.
>
> I had thought the reverse, that Dispose() would perform closures, as with
> using 'using' with Stream objects.

Both functions dispose. They're implemented exactly the same, but Close
or FInish is a more logical name to close the underlying
stream/connection/transaction etc.

See the Close function of the Stream Class (used reflector to get to that):

public virtual void Close()
{
this.Dispose(true);
GC.SuppressFinalize(this);
}


Jesse Houwing

Please note that Dispose method is not private. IDisposable is implemented
explicitly. This requires you to call the method on the reference of the
exact interface type.

"Jon Davis" <jon@REMOVE.ME.PLEASE.jondavis.net> wrote in message
news:eU82pN$mHHA.3888@TK2MSFTNGP03.phx.gbl...
> Why is the IDisposeable implementation of WCF clients private?
>
> I'm glad that you can still Dispose() by casting or with using ( .. ) {
> .. } because IDisposable is indeed implemented but what was the design
> reasoning to make Dispose() private?
>
> Jon
>

"Jesse Houwing" <jesse.houwing@nospam-sogeti.nl> wrote in message
news:%23um3OnEnHHA.3460@TK2MSFTNGP04.phx.gbl...
>* Jon Davis wrote, On 22-5-2007 0:51:
>> I had thought the reverse, that Dispose() would perform closures, as with
>> using 'using' with Stream objects.
>
> Both functions dispose. They're implemented exactly the same, but Close or
> FInish is a more logical name to close the underlying
> stream/connection/transaction etc.
>
> See the Close function of the Stream Class (used reflector to get to
> that):
>
> public virtual void Close()
> {
> this.Dispose(true);
> GC.SuppressFinalize(this);
> }

That may be true, but it isn't obvious, and I don't like the inconsistent
design. SqlConnection has a Close() method, too, but it does not dispose.
http://blog.devstone.com/aaron/archi...06/03/184.aspx This is useful
because you can reopen a closed object. Generally if I see Close() I expect
to be able to reopen it if I want to, but I'm finding that a WCF client is
completely useless once Close() is called--whatever unmanaged resources were
exposed won't be recreated for me, I have to create a whole new WCF client.
Which is annoying because I'm trying to work with an "abstractly configured"
WCF client interface.

Jon

> I'm finding that a WCF client is completely useless once Close() is
> called--whatever unmanaged resources were exposed won't be recreated for
> me, I have to create a whole new WCF client. Which is annoying because I'm
> trying to work with an "abstractly configured" WCF client interface.

Incidentally, what's the deal with Faulted state? I can't
((IDisposable)client).Dispose() because it's in a faulted state. I can't
Close() it because it's in a faulted state. And if I just let it drop out of
scope before I recreate a new client, everything hangs for three seconds!!!!

Jon

Seriously? It causes Dispose() to fail? Eek. Looking at reflector,
Dispose() simply calls Close(), so I would (as you state) expect them
to behave the same... but I do hate it when Dispose() throws... it
makes tidy cleanup a pain...

Marc

"Marc Gravell" <marc.gravell@gmail.com> wrote in message
news:%23Army8QnHHA.4960@TK2MSFTNGP02.phx.gbl...
> Seriously? It causes Dispose() to fail? Eek. Looking at reflector,
> Dispose() simply calls Close(), so I would (as you state) expect them to
> behave the same... but I do hate it when Dispose() throws... it makes tidy
> cleanup a pain...

Yeah, the server is throwing an exception, and passing back a fault. Seeing
that and then trying again on the client side, Close() and Dispose() both
raise exceptions, "because it is in a Faulted state". (And without
Close()ing it, it hangs for seconds when I create and call a new client.)

Finding this I went home last night red-faced mad and wondering if
Microsoft's WCF QA team consists of 12-year-old children. I know that can't
be the case, so I'd like to know the simple answer to this problem.

Jon

> Finding this I went home last night red-faced mad and wondering if
> Microsoft's WCF QA team consists of 12-year-old children. I know that
> can't be the case, so I'd like to know the simple answer to this problem.

It seems calling Abort() instead of Close() when in Faulted state seems to
resolve the 3-second wait issue. Reflection says that Abort() raises the
OnClosing and OnClosed events. It seems the dependency objects are using
delegate hooks to this event (InputQueueChannel<TDisposable>,
LayeredChannel<TInnerChannel>, PeerChannelListenerBase,
PeerDuplexChannelAcceptor, PeerInputChannelAcceptor, PeerOutputChannel,
WrapperSecurityCommunicationObject) ... not sure if any of these are even in
use. I'm surprised that Reflection's Analyze feature supports finding uses
of this event.

Jon