[ACCEPTED]-Calling Dispose() vs when an object goes out scope/method finishes-using-statement

No, objects are not automatically disposed 8 when they go out of scope.

They're not even 7 guaranteed to be disposed if/when they're 6 garbage-collected, although many IDisposable objects 5 implement a "fallback" finaliser 4 to help ensure that they're eventually disposed.

You 3 are resposible for ensuring that any IDisposable objects 2 are disposed, preferably by wrapping them 1 in a using block.

You should use a using {...} block to wrap your IDisposable 8 objects in - the Dispose() method (which for SqlDataReader 7 passes off to the Close() method) will be called 6 when the using block ends. If you do not 5 use using, the object will not be automatically 4 disposed when it goes out of scope - it 3 will be up to the object finalizer, if it 2 has one, to get rid of resources when it 1 is garbage collected

using (SqlDataReader aReader = aCommand.ExecuteReader())
{
    // ... do stuff
}   // aReader.Dispose() called here

I agree with all of the above. You should 27 make sure you call Dispose() yourself, and the easiest 26 way to to this is with the using statement (you 25 can also do this yourself in the finally block 24 - this is more verbose, but sometimes necessary). If 23 you don't do this you can find your application 22 leaking unmanaged resources such as handles, or 21 even unmanaged memory, especially if somewhere 20 underneath all of this some COM components 19 are being used, or calls are being made 18 into the Win32 API. This can obviously lead 17 to performance and stability problems, as 16 well as excessive resource usage.

Just because 15 objects that implement IDisposable "should" implement 14 a finaliser that calls their Dispose(bool disposing) method to 13 free unmanaged resources, is no guarantee 12 that this will happen, so you definitely 11 should not rely on it. See, for example, http://msdn.microsoft.com/en-us/library/b1yfkh5e%28VS.71%29.aspx for 10 more information on this point.

Also, something 9 else to bear in mind, is that if your type 8 has members that are disposable, your type 7 should either implement IDisposable (unless the lifecycle 6 of those members is managed by another type, which 5 obviously might get messy), or, if you only 4 use such members in one method, or to implement 3 one particular piece of functionality, you 2 should consider making them local variables/parameters 1 in the methods that use them.

The Dispose pattern doesn't make any guarantees 6 about which objects will call Dispose on 5 which other objects; it may happen sometimes, but 4 you shouldn't care. Instead, it's your responsibility 3 to make sure Dispose() is called for all 2 IDisposable objects. The best way to do 1 that is with the using statement. For example:

using (SqlDataReader aReader = aCommand.ExecuteReader())
{
    // your code
}

I am puzzled by the statement "In the finally 10 block, the objects which are manually disposed 9 of are those which are set at the class 8 level." By objects set at the class level, do 7 you mean fields? You probably shouldn't 6 be disposing of these within a ordinary 5 method, because then the life-time of the 4 fields is unpredictable, and depends on 3 which methods you happened to have called. It 2 would be better to implement IDisposable 1 and dispose of fields in your Dispose method.