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$**************@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

[Jesse Houwing]

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

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

[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**************@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

[Jon Davis]

"Jesse Houwing" <je***********@nospam-sogeti.nlwrote in message
news:%2****************@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

[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)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

[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**********@gmail.comwrote in message
news:%2****************@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

[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 (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

[Jon Davis]

Alright, so, in conclusion of a long-winded thread where I keep talking to
myself, I must say I am horrified by Microsoft's inconsistency.

IDisposable was always percieved to be the happy, safe haven for getting rid
of objects that use managed resources. If something implemented IDisposable,
Dispose() was always callable. Not so anymore.

((IDisposable)client).Dispose() can only be called on a WCF client if
Close() can be called, because internally it calls Close(). Close() cannot
be called unless basically it's in the Open state; otherwise, you have to
execute Abort() instead, which is not a memeber of IDisposable. This means
that, even though the object does indeed implement IDisposable, its
*SUPPORT* for IDisposable is 100% dependent upon the caller evaluating the
State of the object to determine whether or not it's open. In other words,
Microsoft has establish a new precedent: IDisposable mandates extraneous
state-checking code before its IDisposable implementation is usable, and the
only thing you can do about it is wrap it. I might've opted to create a new
interface, IReallyDispose, but then I'd still have to implement it. I could
create an abstract class, WcfDisposable, but C# doesn't support multiple
inheritance. The best I can do is put a sticky note on my computer monitor
that reads: "WCF client objects don't REALLY implement IDisposable unless
they're Open!" Then I can only hope that I'll pay attention to my stickynote
when I'm going about WCF coding.

Does anyone else besides me find this to be unacceptably stupid and messy? I
really *WANT* to like WCF. I love greenfield projects that use promising new
technology, but when new technology abandons key design patterns like this,
it really gets under my skin.

Jon

[Jon Davis]

Alright, so, in conclusion of a long-winded thread where I keep talking to
myself, I must say I am horrified by Microsoft's inconsistency.

IDisposable was always percieved to be the happy, safe haven for getting rid
of objects that use unmanaged resources. If something implemented
IDisposable, Dispose() was always callable. Not so anymore.

((IDisposable)client).Dispose() can only be called on a WCF client if
Close() can be called, because internally it calls Close(). Close() cannot
be called unless basically it's in the Open state; otherwise, you have to
execute Abort() instead, which is not a memeber of IDisposable. This means
that, even though the object does indeed implement IDisposable, its
*SUPPORT* for IDisposable is 100% dependent upon the caller evaluating the
State of the object to determine whether or not it's open. In other words,
Microsoft has establish a new precedent: IDisposable mandates extraneous
state-checking code before its IDisposable implementation is usable, and the
only thing you can do about it is wrap it. I might've opted to create a new
interface, IReallyDispose, but then I'd still have to implement it. I could
create an abstract class, WcfDisposable, but C# doesn't support multiple
inheritance. The best I can do is put a sticky note on my computer monitor
that reads: "WCF client objects don't REALLY implement IDisposable unless
they're Open!" Then I can only hope that I'll pay attention to my stickynote
when I'm going about WCF coding.

Does anyone else besides me find this to be unacceptably stupid and messy? I
really *WANT* to like WCF. I love greenfield projects that use promising new
technology, but when new technology abandons key design patterns like this,
it really gets under my skin.

Jon

[Helge Jensen]

Jon Davis skrev:

Alright, so, in conclusion of a long-winded thread where I keep talking to
myself, I must say I am horrified by Microsoft's inconsistency.

You've only just scratched the surface yet, and there's som *ugly* old
paint down there related to finalizers which shines through as
Dispose(bool).

Finalization is not ordered wrt. referencing (think about it, how would
you finalize a cyclic chain if it was -- but it's not even ordered for
non-cyclic reference chains).

Because of that, a class with a finalizer (and methods invoked by it)
cannot (safely) use the objects its object references, since they may
already have been finalized.

Many System.* classes (for example Stream) implement IDisposable
"solving" this using the "Dispose(bool)" pattern
(http://msdn2.microsoft.com/en-us/lib...s2xkftw.aspx):

class Foo: IDisposable {
IDisposable.Dispose() {
Dispose(true);
}
protected void Dispose(bool disposing) {
if ( disposing )
// dispose managed resources
// dispose unmanaged resources
}
~Foo() { Dispose(false); }
}

Even more unnerving is the way that object finalization elegibility is
interpreted. Since the finalizer runs on a separate thread an object may
be finalized while a method is still being invoked on it! See
http://msdn2.microsoft.com/en-us/lib...keepalive.aspx.

The "fix" is to GC.KeepAlive(o), but compilers are allowed to optimize
that away in situations where it can prove that GC.KeepAlive is never
run (making the refernce to o dead), for example in:

Foo o = new Foo();
return o.f(); // o may be finalized while o.f is still running
GC.KeepAlive(o);

so to fix *that* you need to write your code in a way that prevents the
compiler from proving that GC.KeepAlive runs, for example:

public static volatile bool fool_the_compiler = true;

Foo o = new Foo();
if ( fool_the_compiler )
return o.f();
GC.KeepAlive(o);
throw new InvalidOperationException(); // must return or throw :)

Happy hacking :)

.....

Well, fortunatly it's not a problem very often in the real world. but it
stinks just the same.

--
Helge

[Marc Gravell]

Sorry for the multi-post; all does not appear well in NNTP-land ;-p

Marc