Do you have to release managed resources in a Dispose method?

Question

Following this MSDN resource, the code

using System;

class BaseClass : IDisposable
{
   // Flag: Has Dispose already been called?
   bool disposed = false;
   
   // Public implementation of Dispose pattern callable by consumers.
   public void Dispose()
   { 
      Dispose(true);
      GC.SuppressFinalize(this);           
   }
   
   // Protected implementation of Dispose pattern.
   protected virtual void Dispose(bool disposing)
   {
      if (disposed)
         return; 
      
      if (disposing) {
         // Free any other managed objects here.
         //
      }
      
      // Free any unmanaged objects here.
      //
      disposed = true;
   }

   ~BaseClass()
   {
      Dispose(false);
   }
}

has a comment about freeing managed resources/objects.

As far as I know, the garbage collector will do that, but is it good practice to actually write such code there, and by such I mean pointing the objects's references to null?

I believe that's the best you can do at "disposing" of a managed resource, although you don't achieve anything in the process, as the garbage collector will do the actual heavy lifting, not you setting their references to null. (The garbage collector will notice that the class itself holding these objects/resources is not used (no references), making this task meaningless)

Thanks!

Answer 1

Note that disposing an object does not frees the allocated memory. It just a way to indicate the end of use of unmanaged resources that your object may be owning.

For example, if your object owns an unmanaged resource like for example a TCP socket, you can just let the garbage collector end everything when it runs, but the socket will be potentially alive until that happen, leading to a situation in which you have many open connections at a given time and the server is rejecting new ones.

This happens when you have a SqlConnection. When you call Dispose, it actually does not close the socket to SqlServer, but returns the connection to a pool where it can be reused. If you do not dispose SqlConnection, on a concurrent system there will be a moment where those objects are candidates to be garbage-collected, but because they are still there holding a connection, at some point you will have too many connections to SqlServer and it may start rejecting the new ones.

Similar thing with a SqlTransaction. If an exception is thrown before you call Commit or Rollback and Dispose is never called, the connection will potentially hold locks on tables, pages, etc... causing performance degradation in other connections.

Even if you call Dispose, a SqlConnection object is still in memory, waiting to be collected, but unusable because the actual socket was returned to a pool. In fact if you Dispose and call any of its methods, it will throw an ObjectDisposedException, indicating that the object is unusable anymore.

And object that implements IDisposable, either owns unamanged resources, or owns other objects that owns unamanged resources. So if you write a repository class that owns a SqlConnection, you will need to implement a cascade Dispose call.

Answer 2

From the same page:

The body of the method consists of two blocks of code:

• A block that frees unmanaged resources. This block executes regardless of the value of the disposing parameter.

• A conditional block that frees managed resources. This block executes if the value of disposing is true. The managed resources that it frees can include:

  • Managed objects that implement IDisposable. The conditional block can be used to call their Dispose implementation. If you have used a safe handle to wrap your unmanaged resource, you should call the SafeHandle.Dispose(Boolean) implementation here.

  • Managed objects that consume large amounts of memory or consume scarce resources. Freeing these objects explicitly in the Dispose method releases them faster than if they were reclaimed non-deterministically by the garbage collector.

So certainly you should free any managed objects that are also disposable, but you could also release any managed objects that use lots of memory or scarce resources.