Developing COM Add-ins for Microsoft Outlook

The primary way to add functionality to Outlook is to develop a COM add-in that can be installed on each user's machine. COM add-ins are the best way to distribute code that you may have originally created or prototyped in Outlook VBA . They are typically used to:

• Add toolbar buttons to Outlook Explorer and Inspector windows and procedures to go with them
• Respond to events from the Outlook Application object
• Respond to other events available in the Outlook Object Model
• Add a property page to the Tools | Options dialog box or a folder's Properties dialog box
• Add functionality too complex to code into an Outlook form
• Beginning in Outlook 2007, add functionality with form regions, the ribbon interface, and custom task panes

Many different tools can be used to build such add-ins, including Visual Basic 6.0, C++, Delphi, Visual Studio .NET and, for Outlook 2003 and later, Visual Studio Tools for Office (VSTO). Two different COM add-in architectures are supported:

• So-called "shared add-ins" that depend on the IDTExtensibility2 interface
• Add-ins built with Visual Studio Tools for Office (VSTO) - only for Outlook 2003 and later

Visual Studio Tools for Office adds support for managed code add-ins, built with VB.NET and C#, for Outlook 2003 and later versions only. We cover the specifics of VSTO add-ins at Creating Outlook Add-ins with Visual Studio Tools for Office.

The resources on this page are relevant to COM add-ins in general and shared (IDTExtensibility2) add-ins in particular.

Documentation

• How to Create a COM Add-in for Outlook
• Building a COM Add-in for Microsoft Office XP Using Microsoft Visual Basic 6.0

For Visual Studio .NET

• Creating Outlook Add-ins with Visual Studio 2005 Tools for Office
• Building Outlook 2002 Add-ins with Visual Basic .NET -- also demonstrates how to connect to an XML web service
• Isolating Microsoft Office Extensions with the COM Shim Wizard Version 2.0 - for Visual Studio 2005
• Adding custom property pages to Outlook 2003 using C#

Design and operational issues

COM add-ins normally should be registered in the Windows Registry in the HKEY_CURRENT_USER (HKCU) hive, rather than HKEY_LOCAL_MACHINE (HKLM). If you register the Add-in in HKLM, it will be available to all users on the machine, but it will not be visible in the COM Add-ins dialog box where the user can remove it if necessary. (On the other hand, if you want to include a COM add-in as part of your standard Outlook installation without allowing the user the option of removing it, registering it in HKLM might be just what you need.)

Startup/shutdown issues:

• You Cannot Fully Quit Outlook When You Use a COM Add-in

Add-ins for multiple Outlook versions

On building add-ins for multiple Outlook versions, Randy Byrne writes in the microsoft.public.office.developer.com.add_ins newsgroup, "The best practice is to compile your Add-in with OL2000 and MSO9.dll. Then your add-in will work with both OL2000 and OL2002, and CommandBar events will work with both versions. If you need to use any specific OL2002 or Office 10.0 Object Library calls, you can use late binding to address those issues. The CommandBar Events are the same in both Office 2000 and Office XP." The same applies to building add-ins for Outlook 2003 and earlier versions.

How to restart a COM add-in

Randy Byrne provided the following steps in the microsoft.public.office.developer.com.add_ins newsgroup:

1. Retrieve the LoadBehavior DWORD for the Add-in under HKCU or HKLM\Software\Microsoft\Office\Outlook\Addins\ProgID where ProgID is the Programmatic Identifier of your Add-in, such as MyOutlookAddin.Connect.
2. Store the LoadBehavior in a variable.
3. Set LoadBehavior = 8
4. Disconnect the Add-in as follows:
   

5.  Reset LoadBehavior to the value you stored in step 2.

Referring to an add-in in other code

The article How to Programmatically Reference a COM Add-in explains how to call procedures in an add-in from other applications. You might shorten the statement

Application.COMAddIns.Item _
("MyAddin.Connect").Object = Me

to simply

AddInInst.Object = Me

For .NET add-ins built with VSTO 2005 or later, you  would take a slightly different approach. See:

• VSTO Add-ins, COMAddIns and RequestComAddInAutomationService  --
  Andrew Whitechapel explains how to expose methods in a VSTO add-in that other add-ins (including VBA) can call.