Why Use the Outlook PIA
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
Starting in Microsoft Office Outlook 98, 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 .NET to COM interoperability, 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.
Using Visual Studio and Visual Studio Tools for Office
It is possible for developers to create managed Outlook solutions outside of Microsoft Visual Studio, but using Visual Studio and Microsoft Visual Studio Tools for the Microsoft Office System 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 Visual Studio Tools for Office to create add-ins that have access to both the Outlook object model and the .NET Framework. At run time, Visual Studio Tools for Office provides 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.
Microsoft Visual Studio 2005 Tools for the 2007 Microsoft Office System or Visual Studio Team System supports development of managed add-ins for Microsoft Office Outlook 2003. To use Visual Studio Tools for Office to develop managed add-ins for Microsoft Office Outlook 2007, you must use Microsoft Visual Studio 2005 Tools for the 2007 Microsoft Office System Second Edition or Microsoft Visual Studio 2008 Tools for the 2007 Microsoft Office System. If you are using Visual Studio 2005 Tools for Office SE, you must install it on one of the following versions of Visual Studio:
Microsoft Visual Studio 2005 Tools for the 2007 Microsoft Office System. Note that Visual Studio 2005 Tools for Office is available as a stand-alone edition of Visual Studio.
Visual Studio Team System. Note that Visual Studio 2005 Tools for Office is included with the Visual Studio Team System products.
Visual Studio 2005 Professional Edition.
For more information about programming managed add-ins for Outlook, see Getting Started Programming Application-Level Add-ins.