C# Classes with members that implement IDisposable

[cgarcia0117]

For any class I write in C# that has a member variable that implements
IDisposable my class implements the IDisposable pattern. I do this to
guarantee the reference to the member is explicitly released and the
object is eligible for garbage collection when my class is disposed or
its' finalizer is called by GC.

My question is whether using this approach is even necessary? My
feeling is yes because it ensures the member is explicitly Disposed
when my Class is, but I'm not certain it provides any real benefit
since the GC will release the reference when it eventually gets to it.

Thanks for the input.

[Nicholas Paldino [.NET/C# MVP]]

You are right, in a class that follows the guidelines put forth by MS
for implementing IDisposable, if you do not call Dispose, the GC will
ultimately dispose of the classes.

However, the class implements IDisposable as an indicator to let you
know that you should take the lifetime of the instance into account, and
call Dispose on it when you are done with it, usually because the resource
is valuable. Things like socket connections, database connections, file
handles and the like all are great candidates for object wrappers with
IDisposable implementations.

So if you have a member field which is an IDisposable instance, and it
lives for the life of your object (as opposed to a specific lifetime defined
by accessing methods/properties on your class), then you should implement
IDisposable, and when using the class, call Dispose when done with the
instance.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

<cg*********@hotmail.comwrote in message
news:11**********************@e34g2000pro.googlegr oups.com...

For any class I write in C# that has a member variable that implements
IDisposable my class implements the IDisposable pattern. I do this to
guarantee the reference to the member is explicitly released and the
object is eligible for garbage collection when my class is disposed or
its' finalizer is called by GC.

My question is whether using this approach is even necessary? My
feeling is yes because it ensures the member is explicitly Disposed
when my Class is, but I'm not certain it provides any real benefit
since the GC will release the reference when it eventually gets to it.

Thanks for the input.

[jpuopolo]

On Nov 8, 9:52 am, [e-mail] wrote:

For any class I write in C# that has a member variable that implements
IDisposable my class implements the IDisposable pattern. I do this to
guarantee the reference to the member is explicitly released and the
object is eligible for garbage collection when my class is disposed or
its' finalizer is called by GC.

My question is whether using this approach is even necessary? My
feeling is yes because it ensures the member is explicitly Disposed
when my Class is, but I'm not certain it provides any real benefit
since the GC will release the reference when it eventually gets to it.

Thanks for the input.

Hi... The real benefit of implementing IDisposable it enables the
application to clean up un-managed resources. Examples include
database connections, file handles and graphics handles (bitmaps,
drawing surfaces, etc.). The .NET classes that manage these resources
are light wrappers around the Windows API. Via the Windows API, these
resources need to be explicitly released.

Are you saying that if your class contains a member that implements
IDisposable, you implement IDisposable on the class itself so that you
can call Dispose explicitly?

jpuopolo

[Chris Nahr]

For any class that has disposable members, you SHOULD implement the
IDisposable interface on that class and make its Dispose method call
Dispose on those disposable members, so that calling code has a way to
deterministically clean up the whole mess via explicit Dispose calls.

However, for any class that has disposable members but DOES NOT add
any raw unmanaged resources of its own, you SHOULD NOT implement the
full Dispose pattern with a finalizer. That pattern provides no
benefit whatsoever since the disposable members (or their nested
classes which hold the actual unmanaged resources) already provide
their own finalizers. You'll only slow down gargabe collection
because finalizers prevent memory from being released quickly.
--
http://www.kynosarges.de

[cgarcia0117]

On Nov 9, 2:11 am, Chris Nahr <[e-mail]:

For any class that has disposable members, you SHOULD implement the
IDisposable interface on that class and make its Dispose method call
Dispose on those disposable members, so that calling code has a way to
deterministically clean up the whole mess via explicit Dispose calls.

However, for any class that has disposable members but DOES NOT add
any raw unmanaged resources of its own, you SHOULD NOT implement the
full Dispose pattern with a finalizer. That pattern provides no
benefit whatsoever since the disposable members (or their nested
classes which hold the actual unmanaged resources) already provide
their own finalizers. You'll only slow down gargabe collection
because finalizers prevent memory from being released quickly.
--http://www.kynosarges.de

Thanks everyone for your input!