Skip to main content

Properly disposing COM objects in your .NET code

Here at work, we are using a third party component where they provide a COM interface.

We're using .NET code so we are using COM interop to use the COM object.

Remember back in the VB6 days when you would set your objects to null when you're done with it? Well, so did someone else here, because that's what I saw.

I'm going to show you an example using the Microsoft Excel Type Library.

Here's some sample code that I wrote that will open up an Excel file and get the text value from a cell in the first worksheet.


    using System;
 
    using Microsoft.Office.Interop.Excel;
 
    internal class Program
    {
        #region Methods
 
        private static void Main(string[] args)
        {
            var app = new Application();
            var books = app.Workbooks;
            var book = books.Open(@"C:\Temp\doc.xlsx");
            var sheets = book.Sheets;
            var sheet = sheets.Item[1] as Worksheet;
            string cellText = string.Empty;
 
            if (sheet != null)
            {
                var cells = sheet.Cells;
                var cell = cells.Item["2""B"as Range;
                if (cell != null)
                {
                    cellText = cell.Text.ToString();
                    cells = null;
                    cell = null;
                }
 
                sheet = null;
                sheets = null;
            }
 
            app.Quit();
 
            books = null;
            book = null;
            app = null;
            Console.WriteLine(cellText);
            Console.ReadLine();
        }
 
        #endregion
    }

See what I did there, I set all of the object references to null, which is how it was done back in the VB6 days, but we're using the .NET CLR. Things are different.


So what the program does is essentially fires up an instance of excel.exe, and then does what I asked it to do which in this case is to just get text from a cell.


The problem is that after my program finishes... excel.exe is still running even though I called "app.Quit()". That's because it can't quit while I still have references to the objects. Simply setting the references to null didn't do the trick. The managed runtime of the .NET CLR doesn't know how to garbage collect unmanaged COM Objects, so even though these references are null, they won't be properly disposed.


So how do you properly dispose of these references? By using Marshal.ReleaseComObject or Marshal.FinalReleaseComObject. Click on the links to read more about each method.


Here's the new version of the program:


    using System;
    using System.Runtime.InteropServices;
 
    using Microsoft.Office.Interop.Excel;
 
    internal class Program
    {
        #region Methods
 
        private static void Main(string[] args)
        {
            var app = new Application();
            var books = app.Workbooks;
            var book = books.Open(@"C:\Temp\doc.xlsx");
            var sheets = book.Sheets;
            var sheet = sheets.Item[1] as Worksheet;
            string cellText = string.Empty;
 
            if (sheet != null)
            {
                var cells = sheet.Cells;
                var cell = cells.Item["2""B"as Range;
                if (cell != null)
                {
                    cellText = cell.Text.ToString();
                    Marshal.FinalReleaseComObject(cells);
                    Marshal.FinalReleaseComObject(cell);
                }
 
                Marshal.FinalReleaseComObject(sheet);
                Marshal.FinalReleaseComObject(sheets);
            }
 
            app.Quit();
 
            Marshal.FinalReleaseComObject(books);
            Marshal.FinalReleaseComObject(book);
            Marshal.FinalReleaseComObject(app);
            Console.WriteLine(cellText);
            Console.ReadLine();
        }
 
        #endregion
    }

Give it a try yourself. Run the app and keep an eye on task manager. When the app gets to the last line, Console.ReadLine(), you'll notice that excel.exe is still running in the first version of the code. Now run the second version and wait for the program to get to the last line, you'll notice that excel.exe is not runnning. 

Useful links:
Mixing deterministic and non-deterministic cleanup


Comments

Popular posts from this blog

Using the BIQU Hermit Crab CAN

I was recently offered to try out the BIQU Hermit Crab CAN.  This was great timing as one of my printers was down due to a bad thermistor cable in the cable drag chain.  I was in the process of removing the wiring and also replacing the drag chain to an open style which allows me to open up each segment and easily add or remove wires.   What is the Hermit Crab? The Hermit Crab is a quick change tool, which allows you to easily and quickly change out your tool. For example, you can change to a FDM extruder, or a laser engraver, or a cutting tool, or whatever you want. The CAN version uses just one USB-C cable (doesn't use USB protocol, just uses that style cable for convenience). The USB-C cable carries the data and power to the hotend. The CAN version has a bunch of nice features such as accelerometer, Neopixel RGB LEDs, and TMC2209 stepper driver. Current setup In this photo, you can see my current setup as I'm in the process of rewiring.  I've got an Orbiter extruder with

Add business days with moment.js

Date . prototype . addBusinessDays = function ( businessDays : number ) { // 5 business days in a week const weeks = Math . floor ( businessDays / 5) ; // Convert business days (5 days in a week) to regular days (7 days in a week) const days = weeks * 7 ; const date = moment ( this ) ; // Convert the incoming date value to a moment value. const newDate = moment ( this ) . add ( days + ( businessDays % 5) , 'days' ) ; if ( newDate . day () < date . day () || newDate . day () % 6 === 0) { // Add 2 more days if we land on a weekend, or we went through a weekend. newDate . add (2 , 'days' ) ; // .add is not pure and will change the underlying value } return newDate . toDate () ; } ;

Debugging .NET Windows Service apps more easily

Here at work, I keep seeing a couple of my fellow developers struggle to debug their Windows Service apps that they're writing.  What they have to do is remove the service, install the new version of the service, start the service, then attach the debugger. If there's an error when the service first starts up, the workaround is to introduce a Thread.Sleep before it actually does anything, giving you enough time to attach the debugger. By default, you can't directly run the service from within Visual Studio. If you try, you get the following message: If you look at the code that actually starts the service, you'll see that it's not that different from a console app. By default, it looks something like this:      internal   static   class   Program     {          ///   <summary>          ///  The main entry point for the application.          ///   </summary>          private   static   void  Main()         {              ServiceBase [] Ser