Why Use the Outlook PIA

Starting in Microsoft Office Outlook 98, Microsoft Outlook provides an object model for developers to integrate Outlook functionality into an application, extend Outlook, or automate Outlook. This object model is designed to work with the Component Object Model (COM) technology. Historically, Outlook application developers developed COM solutions by using Microsoft Visual Basic for Applications (VBA) and Microsoft Visual Basic. However, Outlook solutions developed with VBA have deployment limitations, particularly in corporate environments, and are difficult to update after they are deployed.

The Microsoft .NET Framework provides a rich set of class libraries and support technologies that address many of the limitations of VBA and COM add-ins. However, a managed application needs a bridge between the .NET and COM environments in order to program against a COM object model. An interop assembly is a COM wrapper that acts as the bridge. Consequently, more Outlook solutions are now developed as managed applications that rely on an interop assembly. For more information about how interop assemblies facilitate interoperability between .NET and COM, see Introduction to Interoperability Between COM and .NET.

An interop assembly describes COM types and enables managed code to interact with a COM object model. Any number of interop assemblies can exist to describe a given COM type. As publisher of the type library, Outlook provides a Primary Interop Assembly (PIA) that contains the official description of the COM-based Outlook object model. In general, it is best to use the Outlook PIA rather than relying on an interop assembly from another source.

It is possible for developers to create managed Outlook solutions outside of Microsoft Visual Studio, but using Visual Studio makes integrating Outlook functionality into managed code much easier. The convenience and ease of development makes it more favorable for add-in developers to migrate from COM to .NET development. At design time, developers can use Microsoft Office development tools in Visual Studio to create add-ins that have access to both the Outlook object model and the .NET Framework. At run time, Office development tools in Visual Studio provide a loader for these add-ins: when a user starts Outlook, this loader starts the common language runtime (CLR), the Visual Studio Tools for Office Runtime, and then loads the add-in assembly. The assembly can capture events raised in Outlook.

To use Office development tools in Visual Studio to develop managed add-ins for Microsoft Outlook 2010, you must install the Office developer tools as a separate component included with one of the following editions of Microsoft Visual Studio 2010:

  • Visual Studio 2010 Professional

  • Visual Studio 2010 Premium

  • Visual Studio 2010 Ultimate

For more information about installing Office development tools in Visual Studio 2010, see Configuring a Computer to Develop Office Solutions. For more information about programming managed add-ins for Outlook, see Getting Started Programming Application-Level Add-ins.