While this is pretty old hat stuff, it appears that the statement “common sense is not always common practice” continues to hold true.
Recently while researching some code, I found several instances where someone neglected to call the Dispose() method on a SqlCommand object. It appears that they believe that calling the Dispose() method on the connection actually called the method on the associated command. Some developers believe that the disposing of the associated connection will dispose of the associated command. Neither of these are the case.
In the beginning, there were many Microsoft Examples that did not call the SqlCommand objects Dispose() method due to the fact that it did not override this method and only called the base method. Based on this knowledge, it was not really necessary to call this method. The problem occurs when we follow this practice for multiple objects and suddenly the method is overridden in a new release of the framework. Just by following this seemingly harmless and potentially logical technique, we have inadvertently introduced latent memory and resource leaks into the code.
The best technique for ensuring that this does not occur is to appropriately use the using keyword or ensure that the dispose() method is called in the finally blocks of any try-catch-finally exception processing to ensure that we always dispose of any object that is disposable.
A hard and fast rule of “If it implements IDisposable, then always call Dispose()” will always keep your code unambiguous and dependable regardless of any modifications in the framework.