This post is the fourth in my series on getting your head around COM Interop. My aim here is not to teach you all the innards of COM Interop, but instead to communicate a few key principles. These principles will (hopefully) make your life a little simpler when coding in .NET against COM components (particularly in relation to getting the COM objects to clean themselves up).

COM Interop Principle #3: Fear the (Hidden) Period

Last week’s post covered the key principle of COM Interop – Fear the Period (aka Full Stop).

As a result, we had the following code:

Option Strict Off
Option Explicit On
Imports msE = Microsoft.Office.Interop.Excel
Imports System.Runtime.InteropServices
Public Class Form1
    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        Dim wb As msE.Workbook
        Dim ws As msE.Worksheet
        Dim xlApp As msE.Application
        '==========================
        xlApp = New msE.Application
        xlApp.DisplayAlerts = False
        xlApp.Interactive = False
        Dim wbs As msE.Workbooks
        wbs = xlApp.Workbooks
        wbs.Add()
        Marshal.ReleaseComObject(wbs)
        wb = xlApp.Workbooks(1)
        Dim wss As msE.Sheets
        wss = wb.Worksheets
        'Clear all but the first worksheet
        For Each wrk As msE.Worksheet In wss
            If wrk.Index > 1 Then wrk.Delete()
        Next
        Marshal.ReleaseComObject(wss)
        ws = wb.Sheets(1)
        xlApp.Visible = True
        Threading.Thread.Sleep(5000)    'So we can see Excel
        wb.Close(False)
        xlApp.Quit()
        Marshal.ReleaseComObject(ws)
        Marshal.ReleaseComObject(wb)
        Marshal.ReleaseComObject(xlApp)
    End Sub
End Class

In the above code, we have diligently followed the two key ways that we learnt to Fear the Period:

• Do not ever allow two periods to be consecutive (as in the above example of xlApp.Workbooks.Add).
• Do not ever allow any periods to appear in the ‘In’ section of a For Each declaration (as in For Each wrk As msE.Worksheet In wb.Worksheets).

Or have we?

The Hidden Period

While not evident at first glance, it actually turns out that in the above code there are hidden periods.

Huh? What are you talking about?

Well, lets take a look at one of the lines of code…

        ws = wb.Sheets(1)

The code is simple enough. We want to get the first worksheet of the workbook – so we are calling the Sheets function on the wb (Workbook) object, passing 1.

Or are we?

Whoops, it seems that Sheets isn’t a function – it is actually a Default Property. This means that:

        ws = wb.Sheets(1)

is just shorthand for:

        ws = wb.Sheets.Item(1)

See – there it is – our hidden period.

So, lets’s add a third practical way to Fear the Period (hidden or otherwise):

• Do not ever allow two periods to be consecutive (as in the above example of xlApp.Workbooks.Add).
• Do not ever allow any periods to appear in the ‘In’ section of a For Each declaration (as in For Each wrk As msE.Worksheet In wb.Worksheets).
• Do not ever call a Default Property.

So, lets incorporate this principle into the original code:

Option Strict Off
Option Explicit On
Imports msE = Microsoft.Office.Interop.Excel
Imports System.Runtime.InteropServices
Public Class Form1
    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        Dim wb As msE.Workbook
        Dim ws As msE.Worksheet
        Dim xlApp As msE.Application
        '==========================
        xlApp = New msE.Application
        xlApp.DisplayAlerts = False
        xlApp.Interactive = False
        Dim wbs As msE.Workbooks
        wbs = xlApp.Workbooks
        wbs.Add()
        wb = wbs.Item(1)
        Marshal.ReleaseComObject(wbs)
        Dim wss As msE.Sheets
        wss = wb.Worksheets
        'Clear all but the first worksheet
        For Each wrk As msE.Worksheet In wss
            If wrk.Index > 1 Then wrk.Delete()
        Next
        ws = wss.Item(1)
        Marshal.ReleaseComObject(wss)
        xlApp.Visible = True
        Threading.Thread.Sleep(5000)    'So we can see Excel
        wb.Close(False)
        xlApp.Quit()
        Marshal.ReleaseComObject(ws)
        Marshal.ReleaseComObject(wb)
        Marshal.ReleaseComObject(xlApp)
    End Sub
End Class

So, did that fix the issue?

Unfortunately not. I know the tension must be killing you, but there is still one more gotcha to address…

So:

COM Interop Principle #3: Fear the (Hidden) Period

Coming up next – COM Interop Principle #4: Watch the Loops.

This post is the third in my series on getting your head around COM Interop. My aim here is not to teach you all the innards of COM Interop, but instead to communicate a few key principles. These principles will (hopefully) make your life a little simpler when coding in .NET against COM components (particularly in relation to getting the COM objects to clean themselves up).

COM Interop Principle #2: Fear the Period

Last week’s post was about what not to do when dealing with COM Interop.

So, what should you do instead? Well, first and foremost you must Fear the Period.

The most powerful weapon in your arsenal when correctly doing COM Interop is Marshal.ReleaseComObject. You can see some examples of its use in the previous two posts in this series. Unfortunately, ReleaseComObject has a natural enemy – the period (or full stop).

So, what does Marshal.ReleaseComObject do? Well, it decrements the reference count of the RCW that you pass to it. Or, in English, it releases the underlying COM object (*).

So, what does the period have to do with anything? Well, lets look at some of the code from the original post…

Option Strict Off
Option Explicit On
Imports msE = Microsoft.Office.Interop.Excel
Imports System.Runtime.InteropServices
Public Class Form1
    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        Dim xlApp As msE.Application
        '==========================
        xlApp = New msE.Application
        xlApp.DisplayAlerts = False
        xlApp.Interactive = False
        xlApp.Workbooks.Add()		<---- Focus your attention on this line
        <snip>
        Marshal.ReleaseComObject(xlApp)
    End Sub
End Class

Looking at the code we can see that xlApp is being cleaned up correctly at the end of the code. But have a look at:

        xlApp.Workbooks.Add()		<---- Focus your attention on this line

Let’s have a think about what that code is doing. We are calling a property on the xlApp object which is returning a ‘temporary’ Workbooks object. Then we are calling the Add method (**) on that ‘temporary’ Workbooks object.

But hold on, where are we cleaning up that ‘temporary’ Workbooks object? (Hint: We aren’t!)

This is why we must Fear the Period. To get the above code to work you must introduce an explicit Workbooks variable – this then allows you to explicitly clean it up. So the code would become:

        Dim wbs As msE.Workbooks
        wbs = xlApp.Workbooks
        wbs.Add()
        Marshal.ReleaseComObject(wbs)

So, how do you Fear the Period in practice?

• Do not ever allow two periods to be consecutive (as in the above example of xlApp.Workbooks.Add).
• Do not ever allow any periods to appear in the ‘In’ section of a For Each declaration (as in For Each wrk As msE.Worksheet In wb.Worksheets).

So, lets incorporate this principle into the original code:

Option Strict Off
Option Explicit On
Imports msE = Microsoft.Office.Interop.Excel
Imports System.Runtime.InteropServices
Public Class Form1
    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        Dim wb As msE.Workbook
        Dim ws As msE.Worksheet
        Dim xlApp As msE.Application
        '==========================
        xlApp = New msE.Application
        xlApp.DisplayAlerts = False
        xlApp.Interactive = False
        Dim wbs As msE.Workbooks
        wbs = xlApp.Workbooks
        wbs.Add()
        Marshal.ReleaseComObject(wbs)
        wb = xlApp.Workbooks(1)
        Dim wss As msE.Sheets
        wss = wb.Worksheets
        'Clear all but the first worksheet
        For Each wrk As msE.Worksheet In wss
            If wrk.Index > 1 Then wrk.Delete()
        Next
        Marshal.ReleaseComObject(wss)
        ws = wb.Sheets(1)
        xlApp.Visible = True
        Threading.Thread.Sleep(5000)    'So we can see Excel
        wb.Close(False)
        xlApp.Quit()
        Marshal.ReleaseComObject(ws)
        Marshal.ReleaseComObject(wb)
        Marshal.ReleaseComObject(xlApp)
    End Sub
End Class

So, did that fix the issue?

Unfortunately not. While Principle #2 is definitely the most important principle when dealing with COM Interop, there are still a couple of gotchas in the original sample that we have yet to address…

So:

COM Interop Principle #2: Fear the Period

Coming up next – COM Interop Principle #3: Fear the (Hidden) Period.

* This is an over-simplification, and there a number of finer points that I am purposely ignoring – to keep the discussion simple.
** Let’s ignore what the Add method actually does for now – it isn’t relevant to this post.

This post is the second in my series on getting your head around COM Interop. My aim here is not to teach you all the innards of COM Interop, but instead to communicate a few key principles. These principles will (hopefully) make your life a little simpler when coding in .NET against COM components (particularly in relation to getting the COM objects to clean themselves up).

COM Interop Principle #1: Don’t Cheat (by relying on the Garbage Collector)

In my previous post, I listed a short code sample that was not behaving as I might have liked. Specifically, it was not closing down Excel when I wanted it to. In that post I called for attempts to get the code ‘working’ without calls to GC.Collect().

But, what if you ignored my requirement to not use GC.Collect()? Well, you would likely have come up with a solution something like this:

Option Strict Off
Option Explicit On
Imports msE = Microsoft.Office.Interop.Excel
Imports System.Runtime.InteropServices
Public Class Form1
    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        Dim wb As msE.Workbook
        Dim ws As msE.Worksheet
        Dim xlApp As msE.Application
        '==========================
        xlApp = New msE.Application
        xlApp.DisplayAlerts = False
        xlApp.Interactive = False
        xlApp.Workbooks.Add()
        wb = xlApp.Workbooks(1)
        'Clear all but the first worksheet
        For Each wrk As msE.Worksheet In wb.Worksheets
            If wrk.Index > 1 Then wrk.Delete()
        Next
        ws = wb.Sheets(1)
        xlApp.Visible = True
        Threading.Thread.Sleep(5000)    'So we can see Excel
        wb.Close(False)
        xlApp.Quit()
        Marshal.ReleaseComObject(ws)
        Marshal.ReleaseComObject(wb)
        Marshal.ReleaseComObject(xlApp)
        GC.Collect()
        GC.Collect()' A couple more for good measure
        GC.Collect()' A couple more for good measure
        GC.WaitForPendingFinalizers()

    End Sub
End Class

So, what is the problem?

There are two:

1. It doesn’t work (well, not on my machines running Visual Studio 2008 on Vista 32-bit, nor my machines running Visual Studio 2003 on XP 32-bit).
2. Even if it did work on your PC (or in your version of the .Net Framework) there is no guarantee that it would work in the future or on other machines.

So:

COM Interop Principle #1: Don’t Cheat (by relying on the Garbage Collector)

As with all principles, there are exceptions! Such as:

• If the lifetime of your RCWs (COM components) is the same as your application (eg you will be loading Excel when your application starts, and closing it when your application closes) then there is little point in cleaning up correctly. You can be confident (not 100% sure, but confident) that all RCWs will be cleaned up when your process shuts down. So, cheating is OK.

Coming up next – COM Interop Principle #2: Fear the Period.

So, you want to get your head around COM Interop? (You don’t? Well, just imagine you did.) You could read Adam Nathan’s 1500 page classic (which I thoroughly recommend) or you could start with something a little simpler.

I am hoping over the next couple of weeks to put together a set of blog posts discussing some tips on how to do COM Interop correctly – particularly in terms of cleaning up after yourself.

As part of this I will be starting with a block of code that isn’t doing what I want (it is based on some real production code). You can copy and paste the code into a new VB.NET project. The question I will be looking at over the coming blog posts is:

What code changes are required to (reliably) make sure Excel is not still running when the method finishes (without calls to GC.Collect)?

Make sure you add a reference to Excel in your project…

Option Strict Off
Option Explicit On
Imports msE = Microsoft.Office.Interop.Excel
Imports System.Runtime.InteropServices  
Public Class Form1
    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        Dim wb As msE.Workbook
        Dim ws As msE.Worksheet
        Dim xlApp As msE.Application
        '==========================  
        xlApp = New msE.Application
        xlApp.DisplayAlerts = False
        xlApp.Interactive = False
        xlApp.Workbooks.Add()
        wb = xlApp.Workbooks(1)
        'Clear all but the first worksheet  
        For Each wrk As msE.Worksheet In wb.Worksheets
            If wrk.Index > 1 Then wrk.Delete()
        Next
        ws = wb.Sheets(1)
        xlApp.Visible = True
        Threading.Thread.Sleep(5000)    'So we can see Excel  
        wb.Close(False)
        xlApp.Quit()
        Marshal.ReleaseComObject(ws)
        Marshal.ReleaseComObject(wb)
        Marshal.ReleaseComObject(xlApp)
        'Your objective is for the EXCEL.EXE process to not be  
        'running by the time you get here...  
        'No use of GC.Collect allowed  
    End Sub
End Class

Feel free to post comments (or email me) with solutions, questions, comments etc…