When to Write a COM Add-In

You must consider a number of issues when deciding whether to develop a COM add-in. Some of the functionality COM add-ins provide in Outlook is similar to other Microsoft Exchange Server and Outlook development technologies, such as the Event Scripting Agent and Server Events in Exchange 2000 (discussed in Chapter 17). For this reason, I've provided three questions to help you determine whether to create a COM add-in or use another technology.

• Do you need to receive events when the Outlook client is not running?     The life span of your COM add-in is controlled by Outlook. When the Outlook process is running, your COM add-in can run and receive events. When Outlook is not running, your add-in is also not running. If you need to receive events when the Outlook client is not running, consider using the Event Scripting Agent or Exchange Server Events; your agent will run on the server, so it will always receive events while the server is running. In Chapter 8, I'll examine a COM add-in that notifies users when an item in a folder changes ”functionality that might be better implemented with the Event Scripting Agent or Exchange Server Events.

• Is performance a big concern for your application?     If so, you should use an add-in because it is loaded in-process with Outlook. However, you must use defensive coding practices to prevent Outlook from crashing. Don't create an add-in that performs expensive lookups or data retrievals when starting because Outlook will wait for the add-in to finish these operations before continuing.

• Is your application event-driven?     Outlook will fire a number of new events that your COM add-in can implement and handle. These events provide you with greater control over the Outlook user interface and Outlook data.