What happens to Outlook add-ins when Outlook goes away?

I tried writing another Outlook extension tonight. This time, a desktop widget to display a dashboard-style at-a-glance view of how busy I am (based on my Microsoft Outlook task list).

screenshot of the app I wrote it to run in the background, and update itself once a minute. This raised an interesting question – what to do with the handle to Outlook.

Getting the handle to Outlook is probably the slowest bit of the app, so I don’t want to do this every minute. But caching a handle and reusing it ad-infinitum probably isn’t safe – what if Outlook is closed or restarted, (or… whatever happens when Windows hibernates?) while the widget app is running? Would the widget hold locks on the Outlook data file and cause a closing Outlook to hang? Or would the widget just fall over the next time it tried to use an invalid handle to the Outlook object model?

A quick bit of testing seemed to suggest that the latter is more often the case. Restarting Outlook while my widget was running caused it to throw a bunch of exceptions.

An MSDN blog by Eric Carter comes at the problem from the other side – Outlook add-ins which hang around after you’ve closed Outlook, when you don’t want them to:

…getting Outlook to shutdown when you write an add-in is pretty hard… If you have outstanding references to Outlook OM objects (which you almost always will) the Outlook add-in doesn’t get shutdown because it is waiting for you to release your Outlook OM objects before it shuts you down…

The solution, though, is more or less the same – register listeners for these Outlook shutdown and startup events. When they happen, handle them by making sure that your app trashes it’s own handles to Outlook. Eric even gives some sample code which shows how this can be done.

In my case, if Outlook is then not running, I can then create a new instance of an Outlook app for use by my widget. By trashing my handle to the Outlook that the user has closed, I make sure that I don’t stop Outlook from completing it’s close operation if it needs to, and that my widget wont start using handles to Outlook which are no longer valid.

If Outlook is started while the widget is running, it captures the startup event. If it’s handle to Outlook is different, it can then trash it’s own handle in favour of the currently running instance.

Looks like a bit of a pain for a developer to have to bother with this, but after a quick bit of sanity testing, it seems to do the trick. To be honest, it looks as if this is a problem which might have been solved with later versions of Visual Studio (I’m still on Visual Studio .NET 2003) – as I’ve seen references to Outlook Support in Visual Studio 2005 Tools for Office which look like this sort of thing has been addressed.

PS – Okay… so I haven’t quite done an app a day as I talked about before. I haven’t really set aside the time to do it. An app a week isn’t too bad though! 🙂

4 Responses to “What happens to Outlook add-ins when Outlook goes away?”

  1. […] For my first app, as a GTD fanatic, I thought I’d write something to play with my task list (again! ) […]

  2. Michael says:

    Hi, it is a nice widget that you have there.
    I understood from your post that this extension is a stand-alone application that gets data from Outlook. Am I right?

  3. Michael says:

    Then I completely understand the pain of letting Outlook close gracefully.
    I didn’t kept a reference to the Outlook handle but I still had to use GC.Collect() and GC.WaitForPendingFinalizers() every time I did some operations with Outlook.
    Also, the code from Eric Carter is very useful.