Precisely BECAUSE it is usually hard to evaluate the factors that affect unmanaged resource consumption, the rule of thumb should be to explicitly dispose such resources.

the using statement is great and all, but it’s only usable within the scope of a method… if you need to hold on to an IDisposable for a longer time, you need to make sure that the containing object explicitly calls .Dispose on the IDisposable, and in fact, i would recommend that in this specific scenario, the containing object implements IDisposable as well

@Sasha – I would say whether or not you explicitly dispose of unmanaged resources is dependent on a number of factors, including whether or not such resources are limited. So, the time at which the resource will be cleaned up is indeterminate? If this doesn’t matter, then I don’t see the problem.

The GC can reclaim memory without any effort; any other kind of resource that is cleaned up (by Dispose() and/or a finalizer) requires significant effort if you don’t do it explicitly. I have seen (and blogged about) many bugs that were caused by non-deterministic finalization.

(1) Do not call obj.Dispose() but allow the GC to do the work for you—it’s a finely tuned beast that alot of thought has gone into. Yes, this even applies to objects that you *know* use unmanaged resources;
(2) When dealing with objects that you know use unmanaged resources always try to use a “using” statement to delimit the scope of use.

Of course (1) and (2) assumes that you’ve correctly implemented the Disposable pattern on anything that you write that directly or indirectly uses unmanaged resources. Be smart about this—I had a colleague who insisted that IDisposable be properly implemented on *all* classes that were written—that’s just silly.