How Do I Extend Outlook to Do…

  • Article

Frequently we come across the question “How do I extend Outlook to do <a task>”. Depending on how extensive the task is, you might look for your answer in one or more of the following ways:

  • Use a search engine to see if someone has posted a solution to a similar question on the Internet.
  • Post your question on a forum such as Outlook for Developers or Visual Studio Tools for Office.
  • Post your question on a social network site, such as the MSDN Office and SharePoint Developer Centers fan page on Facebook.

You can browse and get clues from code samples listed in the following locations on MSDN:

There are close to 100 managed code samples listed on this page in the Outlook 2010 Primary Interop Assembly Reference. For example, How to: Create a Meeting Request, Add Recipients, and Specify a Location.

There are many managed code samples in Visual Basic and C# under this folder and its subfolders, that use the Outlook Primary Interop Assembly (PIA), and are part of Office Development in Visual Studio 2010. For example, How to: Perform Actions When an E-Mail Message Is Received.

There are code samples in Visual Basic for Applications and C# listed on this page in the Outlook 2010 Developer Reference. For example, How to: List the Name and Office Location of Each Manager Belonging to an Exchange Distribution List.

You can download the MFCMAPI sample source files to examine example usage cases for many of the MAPI interfaces, as documented in the Outlook 2010 MAPI Reference.

This topic lists sample tasks that use the APIs available in the Microsoft Outlook 2010 Auxiliary Reference.

Often, you can choose to achieve a task by using the Outlook PIA, object model, Messaging API (MAPI), or Outlook Auxiliary API, or, a combination of these APIs. Other than API support and feasibility, there exists other criteria that you should consider when deciding how you should implement a solution. The following questions may come to mind:

· Apart from the goals of the solution, the target market, and available resources, what other criteria should you consider to select the appropriate API?

· If your solution has to run on earlier versions of Outlook, including Outlook 2003, how does that affect your API choice?

· If your solution has to iterate through Outlook folders that contain thousands of items, and you need to be able to modify those items, which API would work best?

· If your solution relies heavily on Outlook business logic and interacts with other Office applications, is the Outlook object model the best choice?

· What do the object model and MAPI allow you to extend in Outlook?

· If you can use either the object model or MAPI to achieve your task, how should you decide which API to use?

· Do you use a managed or unmanaged language, and do you implement the solution in the same thread as Outlook or as a separate thread?

· What’s the level of technical expertise required to use a certain API?

To determine the best API or technology for your solution, you must first define the goals of your solution:

· The versions of Outlook you intend your solution to support.

· The high-priority scenarios of your solution and, in particular, whether these scenarios involve enumerating, filtering, or modifying folders that contain many Outlook items.

Try to match your scenarios with those that the Outlook object model or the PIA supports. Before, this question required combing through the object model. Now you can refer to Decision Factors for the Object Model or PIA which contains a graphical listing of baseline scenarios supported by all versions of Outlook, followed by additional scenarios supported by Outlook 2007 and Outlook 2010. If the object model (or PIA) of your target Outlook versions supports your scenarios, and your solution does not manipulate folders with many items, you should implement your solution as an add-in, in either a managed or unmanaged language.

If the object model (or PIA) of a target Outlook version does not support some of your scenarios, verify whether MAPI or the Auxiliary APIs meet your needs. You can refer to Decision Factors for MAPI or Decision Factors for the Auxiliary APIs. If MAPI meets your needs, you should implement your solution in unmanaged code. If an auxiliary API solves one of your scenarios, you can use managed or unmanaged code.

If your solution uses MAPI, you must implement it in unmanaged code, such as C++. Otherwise, the decision to use managed or unmanaged code to create the solution generally depends on your available resources and their expertise. As for deciding whether to implement the solution as an add-in or standalone application, choose an add-in to avoid the user constantly invoking the Outlook Object Model Guard, unless your scenario requires manipulation of folders that contain numerous items. In the latter scenario, implementing the solution to run as a background thread can optimize Outlook performance.

If your scenarios include showing social network information or updates in Outlook, you should use the Outlook Social Connector provider extensibility to create a COM-visible DLL. You can do this in either a managed or unmanaged language.

Refer to Selecting an API or Technology for Developing Outlook Solutions for an in-depth analysis of how to determine the appropriate API or APIs for your Outlook scenario. Once you have decided on the APIs or technology to use in your solution, you can refer to additional documentation and code samples, as listed in the earlier part of this article.