.NET – The Garbage Collector and Finalizers

I’m not used to use Finalizers in my everyday job but I always thought that if I use it more frequently I could achieve some extra performance.

Well, I’m a natural lazy programmer and that prevents me from digging deeper and doing some tests to clarify this guess.

Thanks to community, there is always someone ready to share knowledge and help those lazy guys like me.

One of those guys were Andrew Hunter that posted an article named “Understanding Garbage Collection in .NET”.

In is article I found that:

  • 1. The Finalizer execution is non deterministic – it depends on GC and the way it’s operating: concurrent or 2. synchronous.
  • 3. It requires two GC cycles to completely remove the object and memory footprint.
  • 4. Two many objects with Finalizers could slow down GC a lot

This don’t mean that we shouldn’t use Finalizers, but we must take same care when we create Finalizers. The simplified way to Finalizer usage is:

  1. a) Implement System.IDisposable interface
  2. b) move Finalizer code to Dispose method
  3. c) Finish Dispose method execution with a GC.SupressFinalize() operation, this way the GC will know that this object wont need the Finalizer invocation and can be remove immediately.
  4. d) Invoke Dispose method in Finalizer – this way we ensure that external resources were always removed.

A deeper understand on this procedure, also known as the IDisposable Pattern, can be acquired by reading this article (kindly pointed by Luis Abreu).


Using finalizers don’t bring any performance improvement but it’s wrong use can be a vector for severe memory management problems.

When we have a class that own external reference not managed automatically by Runtime then the IDisposable Pattern should be used to ensure the correct memory cleanup.

.NET – Determine Whether an Assembly was compiled in Debug Mode

Finding out whether an assembly was compiled in Debug or Release mode is a task we must do from time to time.

I know two ways of accomplish this:

Either attributes are applied to Assemblies and can be found in the Assembly Manifest but there are a major difference between them:

  • AssemblyConfigurationAttribute must be added by the programmer but is human readable.
  • DebuggableAttribute is added automatically and is always present but is not human readable

You can easily get the Assembly Manifest by using the amazing ILDASM from your Visual Studio Studio Command Prompt:



And if you double click the MANIFEST item you will get all manifest data.

Looking carefully you will find the DebuggableAttribute:


And perhaps the AssemblyConfigurationAttribute:



Locate the AssemblyConfigurationAttribute – this attribute can be easily interpreted: its value can either be Debug or Release



If AssemblyConfigurationAttribute is not present then we must use the DebuggableAttribute to get our goal.

Since we cannot understood the DebuggableAttribute value we have to open the assembly from another tool and read this attribute content. There’s no such tool available out-of-the-box but we can easily create a Command Line tool and use a method similar to:

private bool IsAssemblyDebugBuild(string filepath)
    return IsAssemblyDebugBuild(Assembly.LoadFile(Path.GetFullPath(filepath)));
private bool IsAssemblyDebugBuild(Assembly assembly)
    foreach (var attribute in assembly.GetCustomAttributes(false))
        var debuggableAttribute = attribute as DebuggableAttribute;
        if (debuggableAttribute != null)
            return debuggableAttribute.IsJITTrackingEnabled;
    return false;

or (if you prefer LINQ)

private bool IsAssemblyDebugBuild(Assembly assembly)
    return assembly.GetCustomAttributes(false).Any(
        x => (x as DebuggableAttribute) != null 
            ? (x as DebuggableAttribute).IsJITTrackingEnabled 
            : false);

As you can see … it’s pretty simple.


Tipically I add a pre-build task to my build server so that the AssemblyConfigurationAttribute is added to the CommonAssemblyInfo file with the appropriated value: either “Debug” or “Release”. This way anyone can easily see, using only the ILDASM, which king of compilation was used to generate my assemblies.