Outlook 2003 .NET add-ins with VSTO 2005

[UPDATE] Updated programming advice for VSTO and Outlook 2003/2007.

Now that it is official that VSTO 2005 will provide support for writing .NET add-ins for Outlook 2003 (formerly known as 'Project Elixir'), I can blog some experiences about this new toolkit that is currently in beta.

I have participated in the alpha program for Outlook support in VSTO 2005, and I can tell you that this stuff makes developing add-ins with .NET easier than before. You do not need to bother with superfluous interface methods, COM shims, calling InvokeMember(), shaky event handlers, the Outlook shutdown bug, MSCorEE.DLL, etc. The Outlook add-in template for Visual Studio 2005 is also much better than the one available for VS.NET 2003. E.g. the template is preconfigured to start Outlook when debugging, and some other improvements.

Short intro article on MSDN
Long add-in architecture article on MSDN

Developing and debugging Office 2003 add-ins with VSTO 2005 is a breeze, there are several sample projects with the toolkit that will get you started. You just need to ensure that you keep a reference for all objects you add (menus, toolbars, buttons, etc) for the lifetime of the add-in. If you do not, your event handlers for these object will work for some time, until the garbage collector frees the object reference and thus your event handler. The toolkit samples contain some bugs of this kind.

What you will find out the hard way, is that testing your add-in on another PC is not straightforward as the setup project template still has a way to go until RTM. The generated .MSI package will install the .NET Framework 2.0, the detected dependencies and your component. But it will not install the VSTO 2005 runtime or the Office 2003 PIAs. Refer to these pre-release guidelines for what you need to install on a client/test PC.

This is what I had to do to get my add-in to load (i.e. to make the add-in visible and checked in the Outlook "COM Add-ins" dialog box):

• Copy the VSTAddin.DLL assembly to the .\VSTO\8.0\ folder (this assembly replaces the MSCorEE.DLL used in the COM shim era; referred to as AddinLoader.DLL on MSDN, but it is not named so in beta 2)
• Deploy the .manifest file of my add-in .DLL to the install directory of my add-in
• The setup project did not include any of the required registry settings for Outlook, so I had to export the Outlook add-in registry settings, plus the class ID and prog ID settings of the DLL; and then import them on the test PC
• Modify the "ManifestLocation" path to point to the install directory (note that the "CodeBase" stuff for COM shims have been replaced by the deployment manifest file)

Even after installing all of these components, my add-in would be listed in Outlook, but not loaded, with the standard error message "A runtime error occurred during the loading of the COM add-in". This was caused by another change for .NET add-ins, they are now treated as .NET components and code access security must be configured on the target PC:

• Run the .NET FW 2.0 CASPOL.EXE to grant full trust to the install directory of the add-in (see the end of this MSDN article)

These things has improved a lot in the current VSTO beta (see 'Creating Visual Studio Add-in Projects' details on MSDN) and will surely be improved further in coming betas and RTM.

Note that you might not find the "Microsoft .NET Framework 2.0 Configuration" tool in Control Panel-Administrative Tools after installing the .NET FW 2.0 beta 2. Neither will you find the MMC snap-in, which is installed with VS2005.