Thursday 10 February 2011

Visual Studio Tools for Office Notes

Recently, I've been writing a Visual Studio Tools for Office (or VSTO) application; specifically an addin for Outlook 2007. The relevant versions are Visual C# 2008 and VSTO 3.0. It's been an interesting process and I've discovered a few things about the library that I wanted to make a note of. Specifically, it's worth noting two limitations that anyone needs to be aware of when doing this kind of thing.

Firstly, presumably to aid end users with a more pleasant experience, exceptions are not handled the way you might expect… in most cases they are handled silently by the host application. This is definitely true for the Outlook 2007 plugin I've been building, but from Internet searches it looks like it also happens in at least some (i.e. document-level) Word plugins too. I'm not sure about other types of addin.

Visual Studio creates a class and default method,
ThisAddIn.ThisAddIn_Startup()
and this is the equivalent of Main() for addins as it gets called automatically when the addin is initialised (which usually happens when the host application is loaded). Interestingly, exceptions in the call to this method (and obviously, any nested calls within the addin at this point) operate as you would expect and are reported, but other entry points to your dll through other events do not result in an exception if / when a problem is hit.

Significantly for the developer, this means that whether or not you run the code in debug mode from the VS debugger, you don't get notified of exceptions – instead, the code just silently stops running and control is taken back by the host application (i.e. Outlook) instead of passed to the debugger. Obviously this is a major pain if you're not sure whether something's completed successfully or not, although it's worth pointing out that breakpoints and stepping through the code do still work fine (until you hit an exception, anyway).

The second problem I've had is Outlook specific. I was surprised to find that I cannot easily hook into the Send & Receive functionality. My original idea was to create an account within the standard Outlook account structure and allow users to add it to send / receive groups along with the standard email accounts (it's not actually an email account, but syncs note items). However, it seems that this part of the Outlook 2007 object model is not exposed in the VSTO .net interface: I can't add an account and there is no event when a send & receive takes place, let alone a notification that some specific account should undergo that process.

Now, VSTO is a .net wrapper for a more complex COM API, so it might well be possible using either a pure COM addin or manually accessing the underlying COM interface from a .net language (which I might look into), but it seemed to me to be a surprising omission for a relatively mature API. If anyone can offer any insights (particularly if I've missed anything obvious!), I'd love to know.

No comments:

Post a Comment