We Keep Coding

Does C# automatically "dispose" IDisposable objects when they fall out of scope?

I am writing an ASP.NET Web API. As part of this, I have a class that I found out, during testing, needs to implement IDisposable to ensure managed resources are freed.
So, I implemented IDisposable in my class, and put the code necessary to free the resources in the Dispose() method.
There are many places in my code (hundreds) where I instantiate this object, and in the same line call a method on the new instance. I only need the instance to call the single method.
Here's an example:
// MyObject, a class that needs to be disposed of.
public class MyObject : IDisposable
{
private AnObjectThatMustBeDisposed localObject;
public MyObject()
{
localObject = SomeLibrary.SomeProject.AnObjectThatMustBeDisposed.Create();
}
public void doOperationOne()
{
localObject.DoSomething(1);
}
public string getOperationTwo()
{
return localObject.DoSomething(2);
}
public string getOperationThree()
{
return localObject.DoSomething(3);
}
public bool getOperationFour(string input)
{
return localObject.DoSomethingSpecial(4,input.ToLower());
}
...
public void getOperationOneHundred(DateTime input)
{
localObject.DoSomethingElse(100,input);
}
public void Dispose()
{
localObject.CloseResources();
localObject.FreeUpMemory();
localObject.Close();
localObject.Dispose();
}
}
// A class that makes use of MyObject
public class MyLibraryThatUsesMyObject
{
public void Method1()
{
new MyObject().doOperationOne();
}
public string Method2()
{
return new MyObject().getOperationTwo();
}
public int Method3()
{
return new MyObject().getOperationThree();
}
public bool Method4(string testString)
{
if (testString.Length > 6)
{
if (new MyObject().getOperationFour(testString)) return true;
else return false;
}
else return false;
}
...
public void Method100()
{
new MyObject().doOperationOneHundred(DateTime.Now);
}
}
My question is: Does .NET automatically Dispose() objects when they fall out of scope? Or, do I actually have to do this...
public void Method1()
{
using (MyObject o = new MyObject())
{
o.DoOperationOne();
}
}
...to each method? It wouldn't be hard if I had two or three methods, but if I have tons of methods, this refactoring could take quite a while.
I am not sure how ASP.NET handles requests as they complete - i.e. does the framework give code time to Dispose() things, or does it "cut off" execution as soon as the return is called, not letting things dispose?
The fact that, without implementing IDisposable myself, things inside the MyObject class are failing due to unreleased resources causing leaks, it feels like .NET does not automatically Dispose things. So, if that's the case, can I do something so I don't have to refactor hundreds of methods?
EDIT: I tried simply implementing IDisposable, but my unit test was still able to produce a resource leak. So it would appear that my suspicion that .NET is not automatically disposing is correct. So now my question becomes - how can I force disposing without having to refactor hundreds of methods?

Dispose is not automatically called. If you don't call .Dispose() (either explicitly or via a using statement) the method will never be called.
The only caveat is methods that are implemented with the pattern
public void Dispose()
{
GC.SuppressFinalize(this);
Dispose(true);
}
~MyClass()
{
Dispose(false);
}
bool _isDisposed = false;
protected virtual void Dispose(bool disposeing)
{
if(_isDisposed)
return;
_isDisposed = true;
if(disposing)
{
//Disposed managed code here
}
//Dispose unmanaged code only here.
}
Will have Dispose(false) called on it when the object is finalized, but you are not allowed to dispose (or even access) managed objects (i.e: other stuff that implements .Dispose()) when disposing is false.
You will need to refactor your code if you want your resources disposed correctly.
There is a really, really, good article written by Stephen Cleary "IDisposable: What Your Mother Never Told You About Resource Deallocation" that does a very good job explaining how Dispose works and how to correctly write your own disposeable objects (for example, that caveat pattern I mentioned above is recommended by Microsoft but is actually a very bad pattern to do. Classes should only either hold only managed resources or derive from SafeHandle and only hold a unmanaged resource and possibly other SafeHandles. You should never have a class that holds both managed and unmanaged resources nor a single class that holds multiple unmanaged resources)

I am not sure how ASP.NET handles requests as they complete - i.e. does the framework give code time to Dispose() things, or does it "cut off" execution as soon as the return is called, not letting things dispose?
My answer will try to answer the specific question above since you have gotten answers to your other question.
In the MVC framework there is a class that creates controllers. It is named DefaultControllerFactory and it has this method:
public virtual void ReleaseController(IController controller)
{
IDisposable disposable = controller as IDisposable;
if (disposable != null)
{
disposable.Dispose();
}
}
Please note the parameter the above method takes: IController. So it passes your controller class (since all controllers implement that interface by deriving the BaseController) and if your controller implements IDisposable, it will cast it and then call Dispose() on it. So it gives you a chance to do whatever cleanup you need to do.
If you have rolled your own factory and you are not using the DefaultControllerFactory then make sure you are doing the same thing and calling the Dispose on the controllers.
I got the above source code from MVC's Source Code.

No, the CLR will never call Dispose on your object when it goes out of scope. It will, however, call the class destructor (which must be explicitly overridden).
Note: The example that follows is not intended to demonstrate what should be done in production code. The practice recommended by Microsoft can be found here.
Consider the following class:
public class MyDisposable : IDisposable
{
public void Dispose()
{
Console.WriteLine("Disposing this disposable instance.");
}
// Note: This is not the right way to implement the dispose pattern. See
// the MSDN docs on the recommended pattern.
~MyDisposable()
{
Dispose();
}
}
Now, write this method that uses it, and set a break point on the MyDispoable.Dispose method.
private static void UseDisposable()
{
Console.WriteLine("Enter");
var disposable = new MyDisposable();
Console.WriteLine("Exit");
}
What you will see is that, when leaving this scope, not only is the Dispose on MyDisposable not called, but neither is the finalizer. This means that the locals you created in your method are not cleaned up at the end of the method, even though they are local to the method (not returned to the caller, or assigned to any other object).
The way that I try to manage disposable resources in my own code is by not using them as class members, and put all of them inside of using blocks. Keep in mind that a using is only syntax sugar for try {...} finally {...}, though.
Now, I think your question is more about ASP.NET than the CLR. I am not sure of what ASP.NET does to handle disposable resources. If you are using the resource inside of a Controller, then have a go at implementing IDisposable, and using a break point to see if it gets called after your method completes. That's a scenario that I'm not as sure about, but it seems reasonable that it may work that way.
Edit: See the answer from #CodingYoshi regarding ASP.NET controller disposal. It turns out that MVC will deterministically call dispose, so some of your refactoring may be slightly more simple.

Order of disposal for base classes

When a derived class overrides Dispose should the base class Dipose be called first before the derived class disposes of any local resources?
The reason I ask is because someone on our team is saying yes for every scenario, I'm trying to work out if this is good idea or just 'cargo cult' programming, I don't have a strong view either way.
Before:
public override void Dispose()
{
base.Dispose();
if (!_isDisposed)
{
_isDisposed = true;
if (_foo != null)
{
_foo.Dispose();
}
}
}
After:
public override void Dispose()
{
if (!_isDisposed)
{
_isDisposed = true;
if (_foo != null)
{
_foo.Dispose();
}
}
base.Dispose();
}
Note: I'm not looking for how to implement the basic dispose pattern but more clarification from peoples experiences.

"It depends"
You can't have a hard-and-fast rule for this, because the order you need to call dispose will depend on the implementation of the classes.
Sometimes you might want it at the start, sometimes at the end, and sometimes in the middle. Most of the time, it probably won't matter.
Generally speaking, people seem to call it first (in the absence of any other reason to call it at a different time).
One reason to lean towards calling it first is that then the derived class has a chance to do special stuff afterwards if it needs to.

You should think about the consequences of the different approaches. In most cases, the IDisposable objects owned by the base class will be independent of those owned by the derived class, and the order of disposal won't matter, provided none of the Dispose methods throws an Exception (*).
If it's critical to release an IDisposable resource, you could consider using try/finally to ensure all Dispose methods are called - but this isn't universally done. For example, the System.Component.Container class manages and disposes multiple IDisposable objects, but makes no attempt to ensure they are all disposed if an exception is thrown.
(*) It's perfectly legitimate for Dispose to throw: for example a FileStream might attempt to flush data to a network resource that's no longer available during Dispose.

Dispose object in the reverse order to create. So firstly is created base class, so it should be dispose in the end, and so on...

Do this dispose the child objects or not?

I have two classes, say class MyFirstClass and MyAnotherClass , MyAnotherClass is implementing IDiposable interface.
public class MyFirstClass
{
public string xyz{get;set;} ..... and so on
}
public class MyAnotherClass : IDisposable
{
private readonly MyFirstClass objFc = new MyFirstClass();
public static void MyStaticMethod()
{
var objOfFirstClass = new MyFirstClass();
// something with above object
}
public void MyNonStaticMethod()
{
// do something with objFc
}
#region Implementation of IDisposable
.... my implementations
#endregion
}
Now I have one more class where I am calling MyAnotherClass , something like this
using(var anotherObj = new MyAnotherClass())
{
// call both static and non static methods here, just for sake of example.
// some pretty cool stuffs goes here... :)
}
So I would like to know, should I worry about the cleanup scenario of my objects? Also, what will happen to my ObjFC (inside non static) and the objOfFirstClass (inside static).
AFAIK, using will take care of everything...but i need to know more...

objOfFirstClass is a local variable in a method. It will be eligible for garbage collection once the method is exited. It won't be disposed as such because it doesn't implement IDisposable.
objFc will be eligible for garbage collection when its parent object goes out of scope. Again, this is nothing to do with disposing it.
Dispose/IDisposable is used when there is clean up other than simple memory management to be done. The CLR handles cleaning up the memory for you using garbage collection. using is a nice way of ensuring that an object implementing IDisposable has its Dispose method called when you have finished with it - but if all you are after is memory management, you don't need to use it.

IDisposable indicates that an object is using resources other than managed memory; for example, file handles. The Dispose method is supposed to handle the clean-up of these resources (and that's what your implementation should do).
Any CLR-native object (e.g. those in your example) is garbage collected by the CLR when no more references to it exist (more specifically, by a mechanism called the garbage collector or GC); IDisposable is unnecessary in these cases.
In order to make use of IDisposable you have to call Dispose yourself (or use using, which is just syntactic sugar). It isn't called automatically by the GC.

There is not any magic behind IDisposable except that using calls the Dispose method.
As the class MyFirstClass does not implement IDisposable, there is no need to worry about instances of this class - they should not have anything to dispose.
If you have fields or variables that need to be disposed, you have to call Dispose. Additionally, you should implement a destructor that calls the Dispose method, as the reference proposes:
~MyClass() {
Dispose(false);
}
Where the boolean parameter specifies that fields should not be disposed, in this case. For details, see the linked msdn page.

IDispose disposes the class MyAnotherClass. This means that local variables of the MyFirstClass object are pointing to nothing. Therefore, they are reclaimed once the garbage collector runs.

IDisposable Question

Say I have the following:
public abstract class ControlLimitBase : IDisposable
{
}
public abstract class UpperAlarmLimit : ControlLimitBase
{
}
public class CdsUpperAlarmLimit : UpperAlarmLimit
{
}
Two Questions:
1.
I'm a little confused on when my IDisposable members would actually get called. Would they get called when an instance of CdsUpperAlarmLimit goes out of scope?
2.
How would I handle disposing of objects created in the CdsUpperAlarmLimit class? Should this also derive from IDisposable?

Dispose() is never called automatically - it depends on how the code is actually used.
1.) Dispose() is called when you specifically call Dispose():
myAlarm.Dispose();
2.) Dispose() is called at the end of a using block using an instance of your type.
using(var myAlarm = new CdsUpperAlarmLimit())
{
}
The using block is syntactic sugar for a try/finally block with a call to Dispose() on the object "being used" in the finally block.

No, IDisposable won't be called just automatically. You'd normally call Dispose with a using statement, like this:
using (ControlLimitBase limit = new UpperAlarmLimit())
{
// Code using the limit
}
This is effectively a try/finally block, so Dispose will be called however you leave the block.
CdsUpperAlarmLimit already implements IDisposable indirectly. If you follow the normal pattern for implementing IDisposable in non-sealed classes, you'll override void Dispose(bool disposing) and dispose your composed resources there.
Note that the garbage collector does not call Dispose itself - although it can call a finalizer. You should rarely use a finalizer unless you have a direct handle on unmanaged resources though.
To be honest, I usually find it's worth trying to change the design to avoid needing to keep hold of unmanaged resources in classes - implementing IDisposable properly in the general case is frankly a pain. It's not so bad if your class is sealed (no need for the extra method; just implement the Dispose() method) - but it still means your clients need to be aware of it, so that they can use an appropriate using statement.

IDisposable has one member, Dispose().
This is called when you choose to call it. Most typically that's done for you by the framework with the using block syntactic sugar.

I'm a little confused on when my IDisposable members would actually get called. Would they get called when an instance of CdsUpperAlarmLimit goes out of scope?
No. Its get called when you use using construct as:
using(var inst = new CdsUpperAlarmLimit())
{
//...
}//<-------- here inst.Dispose() gets called.
But it doesn't get called if you write this:
{
var inst = new CdsUpperAlarmLimit();
//...
}//<-------- here inst.Dispose() does NOT get called.
However, you can write this as well:
var inst = new CdsUpperAlarmLimit();
using( inst )
{
//...
}//<-------- here inst.Dispose() gets called.

The best practice recommend when you implement Dispose() method in non sealed class you should have a virtual method for your derived classes to override.
Read more on Dispose pattern here http://www.codeproject.com/KB/cs/idisposable.aspx

when using an IDisposable object, it's always good to use it this way:
using(var disposable = new DisposableObject())
{
// do you stuff with disposable
}
After the using block has been run, the Dispose method will be called on the IDisposable object. Otherwise you would need to call Dispose manually.

When someone calls .Dispose on it.
No, it already implements it through inheritance.

IDisposable is implemented when you want to indicate that your resource has dependencies that must be explicitly unloaded and cleaned up. As such, IDisposable is never called automatically (like with Garbage Collection).
Generally, to handle IDisposables, you should wrap their usage in a using block
using(var x = new CdsUpperAlarmLimit()) { ... }
this compiles to:
CdsUpperAlarmLimit x = null;
try
{
x = new CdsUpperAlarmLimit();
...
}
finally
{
x.Dispose();
}
So, back to topic, if your type, CdsUpperAlarmLimit, is implementing IDisposable, it's saying to the world: "I have stuff that must be disposed". Common reasons for this would be:
CdsUpperAlarmLimit keeps some OTHER IDisposable resources (like FileStreams, ObjectContexts, Timers, etc.) and when CdsUpperAlarmLimit is done being used, it needs to make sure the FileStreams, ObjectContexts, Timers, etc. also get Dispose called.
CdsUpperAlarmLimit is using unmanaged resources or memory and must clean up when it's done or there will be a memory leak

C# disposable objects

Are there some advices about how I should deal with the IDisposable object sequences?
For example, I have a method that builds a IEnumerable<System.Drawing.Image> sequence and
at some point I would need to dispose that objects manually, because otherwise this might lead to some leaks.
Now, is there a way to bind the Dispose() call to garbage collector actions, because I want these objects disposed right in the moment they are no longer accessible from other code parts?
**Or maybe you could advice me some other approach? **
Generally, this seems to be the same problem as it comes, for example, in unmanaged C++ without shared pointers, where you can have a method:
SomeObject* AllocateAndConstruct();
and then you can't be sure when to dispose it, if you don't use code contracts or don't state something in the comments.
I guess the situation with disposable objects is pretty the same, but I hope there is an appropriate solution for this.

(from the question)
Now, is there a way to bind the
Dispose() call to garbage collector
actions, because I want these objects
disposed right in the moment they are
no longer accessible from other code
parts?
GC doesn't happen immediately when your object goes out of scope / reach; it is non-deterministic. By the time GC sees it, there is no point doing anything else (that isn't already handled by the finalizer), as it is too late.
The trick, then, is to know when you are done with it, and call Dispose() yourself. In many cases using achieves this. For example you could write a class that implements IDisposable and encapsulates a set of Images - and wrap your use of that encapsulating object with using. The Dispose() on the wrapper could Dispose() all the images held.
i.e.
using(var imageWrapper = GetImages()) {
foreach(var image in imageWrapper) {
...
}
// etc
} // assume imageWrapper is something you write, which disposes the child items
however, this is a bit trickier if you are displaying the data on the UI. There is no shortcut there; you will have to track when you are done with each image, or accept non-deterministic finalization.

If you want to determiniscally dispose of the objects in the collection, you should call Dispose on each:
myImages.ToList().ForEach(image => image.Dispose());
If you don't do this, and if your objects become unreachable, the GC will eventually run and release them.
Now, if you don't want to manually code the Dispose calls, you can create a wrapper class that implements IDisposable and use it through a using statement:
using (myImages.AsDisposable()) {
// ... process the images
}
This is the needed "infrastructure":
public class DisposableCollectionWrapper<D> : IDisposable
where D : IDisposable {
private readonly IEnumerable<D> _disposables;
public DisposableCollectionWrapper(IEnumerable<D> disposables) {
_disposables = disposables;
}
public void Dispose() {
if (_disposables == null) return;
foreach (var disposable in _disposables) {
disposable.Dispose();
}
}
}
public static class CollectionExtensions {
public static IDisposable AsDisposable<D>(this IEnumerable<D> self)
where D : IDisposable {
return new DisposableCollectionWrapper<D>(self);
}
}
Also notice that this is not the same as the situation you described with C++. In C++, if you don't delete your object, you have a genuine memory leak. In C#, if you don't dispose of your object, the garbage collector will eventually run and clean it up.

You should design your system in a way that you know when the resources are no longer needed. In the worst case, they'll be eventually disposed when the garbage collector gets to it, but the point of IDisposable is that you can release important resources earlier.
This "earlier" is up to you to define, for example, you can release them when the window that's using them closes, or when your unit of work finishes doing whatever operations on them. But at some point, some object should "own" these resources, and therefore should know when they're no longer needed.

You can use the 'using' block, to make sure, the IDisposable is disposed as soon the block is left. The compiler does encapsulate such blocks into try - finally statements in order to make sure, Dispose is called in any case when leaving the block.
By using a finalizer, one can make the GC call the Dispose method for those objects which where "missed" somehow. However, implementing a finalizer is more expensive and decreases the garbage collection efficiency - and possibly the overall performance of your application. So if any possible, you should try to make sure to dispose your IDisposables on your own; deterministically:
public class Context : IDisposable {
List<IDisposable> m_disposable = new List<IDisposable>();
public void AddDisposable(IDisposable disposable) {
m_disposable.Add(disposable);
}
public void Dispose() {
foreach (IDisposable disp in m_disposable)
disp.Dispose();
}
// the Context class is used that way:
static void Main(string[] args) {
using (Context context = new Context()) {
// create your images here, add each to the context
context.AddDisposable(image);
// add more objects here
} // <- leaving the scope will dispose the context
}
}
By using some clever design, the process of adding objects to the context may can get even more easier. One might give the context to the creation method or publish it via a static singleton. That way, it would be available for child method scopes as well - without having to pass a reference to the contex around. By utilizing that scheme it is even possible, to simulate an artificial destructor functionality like f.e. known from C++.

The neat method would be to create your own generic collection class that implements IDisposable. When this collection class is Disposed() ask for each element if it implements IDisposed, and if so Dispose it.
Example (look elsewhere if you don't know about the IDisposable pattern)
public class MyDisposableList<T> : List<T> : IDisposable
{
private bool disposed = false;
~MyDisposableList()
{
Dispose(false);
}
public void Dispose()
{
Dispose(true);
}
protected void Dispose(bool disposing)
{
if (!disposed)
{
foreach (T myT in this)
{
IDisposable myDisposableT = myT as IDisposable;
if (myDisposableT != null)
{
myDisposableT.Dispose();
}
myT = null;
}
this.Clear();
this.TrimExcess();
disposed = true;
}
}
...
}
usage:
using (MyDisposableList<System.Drawing.Bitmap> myList = new ...)
{
// add bitmaps to the list (bitmaps are IDisposable)
// use the elements in the list
}
The end of the using statement automatically Disposes myList, and thus all bitMaps in myList
By the way: if you loaded the bitmap from a file and you forgot to Dispose() the bitmap you don't know when you can delete that file.

You can call GC.Collect() if you really was to dispose those objects right away but to my understanding it is up to the GC to decide whether to collect the memory.
This in turn will call the Finalize() method for each object that should be released.
Note that if the collection goes out of scope the GC will eventually collect the memory used by the images.
You can also use the using construct if you use a collection that implements IDisposeable. That will guarantee that the objects will be disposed exactly when the collection goes out of scope (or nearly after the end of the scope).