Lets look at what MSDN has to say. As per the msdn

using block Defines a scope, outside of which an object or objects will be disposed.

The using statement allows the programmer to specify when objects that use resources should release them. The object provided to the using statement must implement the IDisposable interface. This interface provides the Dispose method, which should release the object’s resources.

Surprisingly even MSDN does not clarify how does this happen under the hood. It only says the object has to implement IDisposable interface that provides Dispose method on the object implementing the interface.  So to dispose the object it will need to call the Dispose method on the object which will cleanup and release the resources used by the object.

This led me to write some code and analyze the generated IL where I found the answers. Have a look at this code. I’ve written a class Car and made it IDisposable so that I can club its’ lifetime with using block.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace BlogSamples
{
    public class Car : IDisposable
    {
        public Car(int id)
        {
            this.Id = id;
        }

        public int Id { get; set; }

        public void Run()
        {
            Console.WriteLine("Car {0} is running.", this.Id.ToString());
        }

        #region IDisposable Members

        public void Dispose()
        {
            Console.WriteLine("Releasing resources used by Car object : " + this.Id.ToString());
        }

        #endregion
    }
}

Here’s my client-code. A sample ConsoleApplication that uses the Car object within the using block.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace BlogSamples
{
    class Program
    {
        static void Main(string[] args)
        {
            using (Car myCar = new Car(1))
            {
                myCar.Run();
            }
        }
    }
}

The output was obvious. Immediately after the using block the Dispose method of the Car object is called. Note that there are no signs of Dispose() method being called explicitly, still the method is called. Lets look at the generated IL.

.method private hidebysig static void  Main(string[] args) cil managed
{
  .entrypoint
  // Code size       37 (0x25)
  .maxstack  2
  .locals init ([0] class BlogSamples.Car myCar,
           [1] bool CS$4$0000)
  IL_0000:  nop
  IL_0001:  ldc.i4.1
  IL_0002:  newobj     instance void BlogSamples.Car::.ctor(int32)
  IL_0007:  stloc.0
  .try
  {
    IL_0008:  nop
    IL_0009:  ldloc.0
    IL_000a:  callvirt   instance void BlogSamples.Car::Run()
    IL_000f:  nop
    IL_0010:  nop
    IL_0011:  leave.s    IL_0023
  }  // end .try
  finally
  {
    IL_0013:  ldloc.0
    IL_0014:  ldnull
    IL_0015:  ceq
    IL_0017:  stloc.1
    IL_0018:  ldloc.1
    IL_0019:  brtrue.s   IL_0022
    IL_001b:  ldloc.0
    IL_001c:  callvirt   instance void [mscorlib]System.IDisposable::Dispose()
    IL_0021:  nop
    IL_0022:  endfinally
  }  // end handler
  IL_0023:  nop
  IL_0024:  ret
} // end of method Program::Main

Do you spot that compiler has introduced try/finally block and replaced it with using block. But why did compiler do that ? Lets observe the code and attempt to write similar C# code for better understanding. After careful analysis and reverse-engineering the equivalent C# code would look something as following.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace BlogSamples
{
    class Program
    {
        static void Main(string[] args)
        {
            //Declare myCar object with FullName of the type as seen in IL.
            BlogSamples.Car myCar;

            //Instantiate the object by calling the constructor, matching the flow of IL.
            myCar = new Car(1);

            try
            {
                myCar.Run();
            }
            finally
            {
                if(myCar != null)
                    myCar.Dispose();
            }
        }
    }
}

Above code is very clear. All it does is replace the code within the using block into the try block and calls the Dispose() method of the object in the finally block. As we all know, the code written in finally block gets executed in any situation even in case of any handled or un-handled exception. And this is how the using block ensures that the objects used with the using block are disposed for sure.

In fact using block is just a syntactic sugar for this pattern of code.

Some of you might wonder, how does the generated IL of the new reverse-engineered code look like. The IL of the reverse-engineered looks like this.

.method private hidebysig static void  Main(string[] args) cil managed
{
  .entrypoint
  // Code size       31 (0x1f)
  .maxstack  2
  .locals init ([0] class BlogSamples.Car myCar)
  IL_0000:  nop
  IL_0001:  ldc.i4.1
  IL_0002:  newobj     instance void BlogSamples.Car::.ctor(int32)
  IL_0007:  stloc.0
  .try
  {
    IL_0008:  nop
    IL_0009:  ldloc.0
    IL_000a:  callvirt   instance void BlogSamples.Car::Run()
    IL_000f:  nop
    IL_0010:  nop
    IL_0011:  leave.s    IL_001d
  }  // end .try
  finally
  {
    IL_0013:  nop
    IL_0014:  ldloc.0
    IL_0015:  callvirt   instance void BlogSamples.Car::Dispose()
    IL_001a:  nop
    IL_001b:  nop
    IL_001c:  endfinally
  }  // end handler
  IL_001d:  nop
  IL_001e:  ret
} // end of method Program::Main

Needless to mention that the IL in both the cases is identical to each other which proves the point that the using block is nothing but a syntactic sugar.

You might ask what if the constructor throws an exception. In this case the control would not move forward and never enter the proceeding try block. The object myCar still remains null. However you can wrap the using block in a try/catch block as shown below and handle the situation gracefully.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace BlogSamples
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                using (Car myCar = new Car(1))
                {
                    myCar.Run();
                }
            }
            catch
            {
                //Handle the situation gracefully.
            }
        }
    }
}

But why C# designers did not wrap object construction within the try block.

The reason is simple. If you wrap both declaration and instantiation within the try block then the object would be out of scope for the proceeding finally block and the code will not compile at because, for finally block the object hardly exists. If you only wrap the construction in the try block and keep declaration before the try block, even in that case the it will not compile since it finds use of an unassigned variable which is not allowed in C#.

You always help the next generation by sharing and giving whatever they need with whatever you can deliver. I got an opportunity to deliver a session on .net fundamentals last week at a good company out here. They wanted me to take a session on .net fundamentals and basics. Definitely, I opted for that. Believe me though I’ve been working on that platform for a long while now, to comprehend the contents in a presentation and a session of two hours was quite a challenging task. After putting lot of efforts, I could some how managed to do that.

It started out well, and eventually I dragged it towards an endless discussion which everybody just enjoyed it. We discussed in detail on CTS, CLS and many more issues. I inspired them to ask questions be it silly or meaningful, but they must ask. I had to gain them the confidence for working on .net platform since some of them were just college pass-outs and freshers hence.

With that note, I’m publishing my presentation on this blog which I showcased in the event. Hope it might help some one out there!

Topics: Microsoft .Net Fundamentals and Basics

Download Office 2003 Format

Download Office 2007 Format (preferable)

Ruchit S.