When should I dispose my objects in .NET?

Question

For general code, do I really need to dispose an object? Can I just ignore it for the most part or is it a good idea to always dispose an object when your 100% sure you don't need it anymore?

Answer 1

Relying on the GC 'works' in most instances. The classic exception is when you have a resource heavy interaction - in that instance it is best to explicilty dispose.

obvious eg.

using (var conn = new SqlConnection(connString)) {}

'Using' blocks are definitely the cleanest and most robust method of ensuring that objects are disposed of correctly. 'Using' blocks can be leveraged with any objects that implements IDisposable.

Answer 2

When you're done with an object you can forget about it. As long as it's not referenced anywhere then it's as good as gone. The memory it uses is freed up when the garbage collector feels like it.

Answer 3

If the object implements IDisposable, you should dispose of it as soon as you are done with it. The easiest way is to surround it with a using block:

using (SqlCommand cmd = new SqlCommand(conn)) {
    cmd.ExecuteNonQuery();
}

Answer 4

There are a couple of ways to look at it. One way tries to figure out if it's really necessary to dispose of an object as soon as it's no longer needed, for example using Reflector to see if it really is holding onto unmanaged resources, or if they were incidentally disposed of anyway. The other perspective is to assume that if an object implements IDisposable, it's not your business to determine if Dispose() really needs to be called--you always call it. I think that is the right way to go. Peeking into the private implementation of objects to make decisions about how you should consume them increases your risk of getting coupled to an implementation that could change. An example is the LINQ to SQL DataContext. It implements IDispose but mostly cleans up after itself without the need for an explicit call to Dispose(). My preference is to write code that explicitly disposes anyway, but others have suggested its not necessary.

Of course this all applies to objects that implement IDisposable. It's true that the GC will take care of most everything else without any explicit action on your part, but it's worth reading up a bit on the subtleties of GC behavior (I'm too tired to think of the details right now) to know when to dispose of objects explicitly, and more importantly, when to implement IDispose. There are lots of good articles on the interwebs on the matter.

And as said previously, using(..) { ... } is your friend for IDisposable implementors.

Answer 5

The reason you should always call Dispose() on any type that implements IDisposable, is that it is usually used to signify that the type acquires unmanaged resources. It is especially important that these are freed, and as early as possible. As others have mentioned, using is the prefered way to do this.

Answer 6

No you can get away with calling Dispose in the cases where you are not holding an unmanaged resource. But if your class is holding an unmanaged resource say, a temp file that needs to be deleted, then you will have to explicitly call Dispose.

You can avoid calling Dispose by writing your freeing code in Finalize method but then you are dependent on the Garbage Collector because you are never sure than when Garbage collector will finalize your object. To be on the safe side, if you are designing such a class which holds an unmanaged resource, you can write the same object-freeing code in both Dispose And Finalize method but if you do so, always use SuppressFinalize() in your dispose method because it will prevent the Finalize() method from being called if your object is already on the Finalization Queue.