+13  A: 

They should implement IDisposable if the object owns that resource. There's generally no need to set things to null, although it does no harm.

If you don't own the resource, then clearly you shouldn't dispose of it, and you don't need to implement IDisposable. In my experience it's relatively rare that I have a member variable for a disposable resource which I don't own in my classes though...

Jon Skeet
Jon, in the WinForms world components often 'link' to each other w/o owning something (DataSource). Whether that is such a good pattern is something else.
Henk Holterman
@Henk: That's true. It's very context-dependent, obviously :)
Jon Skeet
A: 

This a good practice yes. When the dispose of such a class is called, it's a good idea to call Dispose on all referenced objects as well.

Gerrie Schenck
It's not the same setting IDisposable references to null and calling Dispose on them, you would never want to do that.
Trap
+1  A: 

Setting to null isn't necessary, but you should call .Dispose() on all of those objects from the parent class's .Dispose().

EDIT: IF AND ONLY IF your class was responsible for creating those objects.

Dan Puzey
Only if that parent class is also responsible for creating the object. Cleaning up resources owned by other classes seems like a risky design to me.
Rob van Groenewoud
Yes, sorry, you're absolutely correct :-)
Dan Puzey
+3  A: 

"Holding a reference" is not the real criterium. When an object logically 'owns' an IDiposable object then Yes, it should implement IDisposable to call Dispose for all owned Disposable objects.
But it should not implement a destructor (Finalizer) .

Henk Holterman
A: 

Yes they should if the reference is owned by the class, FxCop / MS code analysis even have a check for it.

Rob van Groenewoud
A: 

If your class creates the disposable object then your class is responsible for cleaning them up. Since your class won't know when to cleanup unless something tells it to (i don't count destructors) it is the easiest way to make your class implement IDisposable.

If your class uses, but does not create, disposable objects then you should leave cleaning up to the creator of those objects.

dbemerlin
The Creator is often, but not always the Owner.
Henk Holterman
Ownership is not strictly determined as the creator. `StreamReader` takes a `Stream` (created elsewhere) in its constructor, but it logically owns the stream and `StreamReader.Dispose()` calls `Stream.Dispose()`.
280Z28