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

[Jon Davis]

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]

* 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

[Jon Davis]

"Jesse Houwing" <je***********@ nospam-sogeti.nlwrote in message
news:u$******** ******@TK2MSFTN GP04.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

[Jesse Houwing]

* Jon Davis wrote, On 22-5-2007 0:51:

"Jesse Houwing" <je***********@ nospam-sogeti.nlwrote in message
news:u$******** ******@TK2MSFTN GP04.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(tr ue);
GC.SuppressFina lize(this);
}
Jesse Houwing

[Lebesgue]

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" <jo*@REMOVE.ME. PLEASE.jondavis .netwrote in message
news:eU******** ******@TK2MSFTN GP03.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

[Jon Davis]

"Jesse Houwing" <je***********@ nospam-sogeti.nlwrote in message
news:%2******** ********@TK2MSF TNGP04.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(tr ue);
GC.SuppressFina lize(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

[Jon Davis]

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)c lient).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

[Marc Gravell]

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

[Jon Davis]

"Marc Gravell" <ma**********@g mail.comwrote in message
news:%2******** ********@TK2MSF TNGP02.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

[Jon Davis]

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 (InputQueueChan nel<TDisposable >,
LayeredChannel< TInnerChannel>, PeerChannelList enerBase,
PeerDuplexChann elAcceptor, PeerInputChanne lAcceptor, PeerOutputChann el,
WrapperSecurity CommunicationOb ject) ... 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