proper destruction techniques

[DKode]

This should be an easy question.

With all of my dataadapters, when I am done with them i do the
following:

DataAdapter da = new DataAdapter();
// do something with da
da.Dispose();

Is that the proper way to destroy an object when I am done with it? Or
should I be doing:
da = Nothing;

or a combonation of both? I want to make I am getting rid of my objects
correctly to free up memory on the server.

thanks

DKode

[John Puopolo]

Hi...

Certain classes require explicit cleanup. These classes express this need
to the world by implementing IDisposable. If a class exposes a public
Dispose() method, you should call it to clean up resources. To "help" the
garbage collector, you can explicitly set the object reference to null, as
well. Note, however, that calling Dispose() is far more important than
setting the reference to null in terms of cleaning up resources.

A common pattern that has emerged is:

using (MyClassThatNeedsDisposing obj = new MyClassThatNeedsDisposing()) {
// use object
}

This will ensure that Dispose is called on the "obj" instance and the object
will be cleaned up properly to boot! Another pattern is as follows:

Foo f;
try {
f = new Foo();
// use f
} finally {
f.Dispose();
f = null;
}

Hope this helps.

John Puopolo

"DKode" <dk****@gmail.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

This should be an easy question.

With all of my dataadapters, when I am done with them i do the
following:

DataAdapter da = new DataAdapter();
// do something with da
da.Dispose();

Is that the proper way to destroy an object when I am done with it? Or
should I be doing:
da = Nothing;

or a combonation of both? I want to make I am getting rid of my objects
correctly to free up memory on the server.

thanks

DKode

[Amiram Korach]

In the .NET world, the garbage collector cleans the objects for you, except
from objects in unmanaged code or GDI objects (Maybe there are more). Anyway,
if you don't need this dataset anymore, leave it alone. It will be collected
if you don't have a reference to it, e.g. you don't have a way to access it.

"DKode" wrote:

This should be an easy question.

With all of my dataadapters, when I am done with them i do the
following:

DataAdapter da = new DataAdapter();
// do something with da
da.Dispose();

Is that the proper way to destroy an object when I am done with it? Or
should I be doing:
da = Nothing;

or a combonation of both? I want to make I am getting rid of my objects
correctly to free up memory on the server.

thanks

DKode

[Harold Howe]

DataAdapter da = new DataAdapter();
// do something with da
da.Dispose();

Is that the proper way to destroy an object when I am done with it? Or
should I be doing:
da = Nothing;

or a combonation of both? I want to make I am getting rid of my objects
correctly to free up memory on the server.

DataAdapter inherits from Component, which in turn implements
IDisposable and the disposable pattern (just like forms do). Component
surfaces a protected, virtual Dispose(bool) method that is called from
both IDisposable.Dispose and Finalize. DataAdapter and SqlDataAdapter
override the protected Dispose method and do some internal cleanup.

In general, as soon as you are done using a DataAdapter, or any other
class derived from Component, you should call Dispose. If a class
implements IDisposable, it is an indication by the class' designer that
you should call Dispose when you are done using instances of the class.
If you don't, its not the end of the world. The GC will call Finalize
eventually on the object. However, for optimum memory usage, IDisposable
objects should be disposed as soon as possible.

If you use interfaces frequently, often times you may not know whether
an object implements IDisposable. For example, I like to write generic
code that deals with the data interfaces (IDbConnection, IDbDataAdapter,
etc), and these interfaces don't descend from IDisposable. In this case,
you can mix a using statement with a cast.

IDbConnection connection = ConnectionFactory.Create()
using(connection as IDisposable)
{
connection.Open();
...
}

The IL generated by a using statement checks for null before calling
Dispose. If the object implements IDisposable, Dispose is called.
Otherwise, the using statement acts as a NOP.

One last gotcha: dropping a component on a form does not guarantee that
Dispose will get called for that object. Components that implement a
magical constructor (public ImageList(IContainer container)) are added
to the components container of the form, and are automatically disposed
by the boilerplate Dispose method of your derived form. However, the
data classes don't have this constructor, so you have to add a Dispose
call manually.

PS: This seems like a flaw to me. Any component with a non-trivial
dispose method should have this special constructor. Most of the
components don't.

H^2

[DKode]

Harold Howe wrote:

DataAdapter da = new DataAdapter();
// do something with da
da.Dispose();

Is that the proper way to destroy an object when I am done with it? Or should I be doing:
da = Nothing;

or a combonation of both? I want to make I am getting rid of my objects correctly to free up memory on the server.
DataAdapter inherits from Component, which in turn implements
IDisposable and the disposable pattern (just like forms do).

Component surfaces a protected, virtual Dispose(bool) method that is called from both IDisposable.Dispose and Finalize. DataAdapter and SqlDataAdapter override the protected Dispose method and do some internal cleanup.

In general, as soon as you are done using a DataAdapter, or any other class derived from Component, you should call Dispose. If a class
implements IDisposable, it is an indication by the class' designer that you should call Dispose when you are done using instances of the class. If you don't, its not the end of the world. The GC will call Finalize eventually on the object. However, for optimum memory usage, IDisposable objects should be disposed as soon as possible.

If you use interfaces frequently, often times you may not know whether an object implements IDisposable. For example, I like to write generic code that deals with the data interfaces (IDbConnection, IDbDataAdapter, etc), and these interfaces don't descend from IDisposable. In this case, you can mix a using statement with a cast.

IDbConnection connection = ConnectionFactory.Create()
using(connection as IDisposable)
{
connection.Open();
...
}

The IL generated by a using statement checks for null before calling
Dispose. If the object implements IDisposable, Dispose is called.
Otherwise, the using statement acts as a NOP.

One last gotcha: dropping a component on a form does not guarantee that Dispose will get called for that object. Components that implement a
magical constructor (public ImageList(IContainer container)) are added to the components container of the form, and are automatically disposed by the boilerplate Dispose method of your derived form. However, the
data classes don't have this constructor, so you have to add a Dispose call manually.

PS: This seems like a flaw to me. Any component with a non-trivial
dispose method should have this special constructor. Most of the
components don't.

H^2