What C# class objects acquire unmanaged resources? Is there a list?

Question

I was working on serializing and deserializing a class object using XML when I came across this blog post that shows how to do it on Windows Phone 7 using the isolated storage area. Windows Phone 7 is the platform I am developing for:

In this example, the only object he explicitly calls Dispose() on is the TextReader object. I looked up the TextReader object on MSDN and found that the documentation said this:

Releases the unmanaged resources used by the TextReader and optionally releases the managed resources.

So I assume the reason he does this is to release immediately the unmanaged resources acquired by the TextReader object. It would not have occurred to me to do this if it weren't for his blog post. Obviously I don't want to start calling Dispose() on every object in sight, so what is a good rule of thumb for at least investigating when a particular object should have Dispose() called on it or not? Are there some guidelines for this or a list somewhere, at least of the popular .NET objects that require this special handling?

Answer 1

Obviously I don't want to start calling Dispose() on every object in

Wrong.

In general, any object that implements IDisposable should be disposed as soon as you're finished with it, typically using the using statement.

Most objects that do not have unmanaged resources do not implement IDisposable (and do not have Dispose() methods), so you have nothing to worry about.

The only exceptions are base classes that implement IDisposable in case some derived implementations have something to dispose (eg, IEnumerator, Component, or TextReader).
However, it is not always obvious which concrete implementations need to be disposed (and it may change at any time), so you should always dispose them anyway.

Answer 2

Obviously I don't want to start calling Dispose() on every object in sight, so what is a good rule of thumb for at least investigating when a particular object should have Dispose() called on it or not?

This is not a problem. The compiler won't let you call Dispose() on an object that doesn't implement it.

And you should be calling Dispose() for every object that does implement it (which it will do via the IDisposable interface). That is the guideline you should be following. In fact, that's what it means when an object implements IDisposable: that it has unmanaged resources that need to be released.

It becomes much less of a chore if you'll simply wrap the creation and use of the objects in a using statement, e.g.:

using (DisposableObject obj = new DisposableObject(...))
{
    obj.DoWork();
} // obj.Dispose() is automatically called here, even if an exception is thrown

Answer 3

Actually you do have to dispose of objects which implement IDisposable.

The standard way of doing that as opposed to directly calling the Dispose() is:

using(AnyIDisposable obj = ...)
{
    // work with obj here
}
//The Dispose() method is already called here

Answer 4

Please correct me if i'm wrong. As far a i read/understood, all clases of the .NET Framework are managed (to the view of the programmer, although underderlaying they might use unmanaged code), so theoretically you dont need to call Dispose() or using, because the gc will take care. But sometimes it's very recommended to use them, see IDisposable Interface and Which managed classes in .NET Framework allocate (or use) unmanaged memory? and http://blogs.msdn.com/b/kimhamil/archive/2008/11/05/when-to-call-dispose.aspx

EDIT: (you are right noob) For clarification i'll add Nayan answer from IDisposable Interface

It recommended to call dispose or using, when:

1.You class has many objects and there are of lots of cross references. Even though its all managed, GC may not be able to reclaim the memory due to alive references. You get a chance (other than writing a finalizer) to untangle the references and break up the links the way you attached them. Hence, you are helping the GC to reclaim the memory.

2.You have some streams open which are alive till the object of the class dies. Even though such implementations of files/network etc are managed, they go deep down to handles in Win32 mode. Hence, you get a chance to write a Dispose method where you can close the streams. The same is true for GDI objects, and some more.

3.You are writing a class which uses unmanaged resources, and you want to ship your assembly to third parties. You better use disposable pattern to make sure you are able to free the handles to avoid the leakage.

4.Your class implements lots of event handlers and hooks them up to events. The objects of classes which expose the events, like Form etc., will not be freed up by GC since the implementations local to your class (maybe) are still hooked into those events. You can unhook those event handlers in Dispose; again helping GC.