Introducing Outlook Add-in Support in Visual Studio 2005 Tools for Office

  • Article

 

John R. Durant
Microsoft Corporation

Published June 2005
Revised December 2005

Applies to:
    Microsoft Visual Studio 2005 Tools for the Microsoft Office System
    Microsoft Office Outlook 2003

Summary: Microsoft Office Outlook 2003 add-in support for Microsoft Visual Studio 2005 Tools for the Microsoft Office System provides tools to develop, debug, and deploy solutions simply and quickly, including a DLL to tie managed add-ins to Outlook. This provides a simpler framework for creating managed add-ins with improved security. (5 printed pages)

Contents

Introduction
Linking a Managed Add-in to the Host Application
One Plus One Makes Five
Securing the Add-in and Other Benefits
Getting Started
Conclusion
Additional Resources

Introduction

Many people spend much of their day using Microsoft Outlook in general and, increasingly, Microsoft Office Outlook 2003. One of the great strengths of Outlook is that it is extensible. How many times have you written a message about a file that you then forget to attach before sending the message? Smart developers use the extensibility of Outlook and write add-ins to solve problems like this. Add-ins for Outlook range from simple add-ins that have one or two targeted features to elaborate project management or customer relationship management (CRM) systems, all built within the Outlook application context.

Despite the advantages of Outlook add-ins, debugging and deploying them has too often been cumbersome. Microsoft Visual Studio 2005 Tools for the Microsoft Office System (Visual Studio 2005 Tools for Office) aims to streamline the debugging process so that situations like the one in the following image (Figure 1) occur less frequently. The figure shows a customer's description of an attempt to get a COM add-in (authored in unmanaged code) that was created on one computer to run on a different computer.

Feedback from customer struggling with COM add-in deployment (unedited)

Figure 1. Feedback from customer struggling with COM add-in deployment (unedited)

As a solutions developer and professional consultant, I created many COM add-ins, several of them for Outlook, and I was sometimes confused when I tried to debug or deploy my add-ins.

Creating an add-in by using managed code can make things a little more challenging than using unmanaged code. The message in Figure 2 expresses the frustration of a developer who tried to create an add-in for Outlook 2002.

Feedback about debug issues in an Outlook 2002 managed add-in (unedited)

Figure 2. Feedback about debug issues in an Outlook 2002 managed add-in (unedited)

Despite the problems noted by developers in Figure 1 and Figure 2, it is important to remember that there are many successful managed COM add-ins for Office, including add-ins for Outlook. A quick search for Outlook-targeted solutions on the Microsoft Office Marketplace yields more than 100 results. Most of these results are add-ins in both managed and unmanaged code. As of this writing, some of the most popular add-ins for Outlook were created by using the Microsoft .NET Framework. However, for these add-ins to work well, developers employ various techniques to assure that the add-ins load, unload, and otherwise work as planned. One of the most common techniques is to use a COM shim to integrate the add-in with the host application.

Linking a Managed Add-in to the Host Application

A COM shim lets you tie together the COM-based host application, Outlook, and the .NET Framework–based customization. Before the release of Visual Studio 2005 Tools for Office, developers created add-ins that used shims or not. A shim refers to the practice of wedging a small layer between the host application and the managed add-in. The shim is an unmanaged component that enables the managed add-in to connect to the host application.

As Andrew Whitechapel notes in his article, Architecture of the Outlook Add-in Support in Visual Studio 2005 Tools for Office, which describes the Outlook add-in support in Visual Studio 2005 Tools for Office, both techniques (using a simple shim or no shim at all) have noticeable difficulties. A full explanation of earlier limitations that prompted development of the new Outlook add-in support is beyond the scope of this article. What is important to know is that a layer exists between the unmanaged host application and the managed add-in (see Figure 3).

The basic architecture of the managed add-in framework

Figure 3. The basic architecture of the managed add-in framework

Using AddinLoader.dll eliminates some key complexities that developers faced when they created managed add-ins for Outlook by using a shim.

One Plus One Makes Five

Another simplification that you will notice in Visual Studio 2005 Tools for Office is a new interface to implement when you create add-in projects. Previously, the interface for add-ins was IDTExtensibility2. This earlier interface provided five events: OnConnection, OnAddInsUpdate, OnStartupComplete, OnBeginShutdown, and OnDisconnection. The new add-in framework provides two clear and useful events: Startup and Shutdown.

The Startup and Shutdown events come with the new IStartup interface. Now, you can put startup code right where it belongs and shutdown code where it clearly belongs, without having to decide among five sometimes confusing events. Also, these two new events fire more reliably and properly, so you can count on your add-ins to behave as they should.

Securing the Add-in and Other Benefits

While the most obvious benefit of Visual Studio 2005 Tools for Office is simplification of the overall development process, another key feature is improved security. Much has been written about the benefits of the Microsoft .NET Framework. Certain .NET Framework advantages, such as strong types, full object-oriented programming, and improved exception handling, led many developers to write managed customizations for Office, and most often for Outlook.

The support for Outlook add-ins in Visual Studio 2005 Tools for Office also helps you to take advantage of the code access security model features in the .NET Framework.

Now you can write Outlook add-ins that comply with the security model in Microsoft .NET. You can create and deploy an add-in that must be granted FullTrust in order to run on the target computer. The security settings within the host application do not prevail in determining whether the add-in is enabled. Although it is possible to create managed Outlook add-ins that enjoy these same security benefits without relying on the tools in Visual Studio 2005 Tools for Office, the new tools in this release make the development experience simpler. When you use the new tools to debug your add-in, the security settings are automatically configured for you on the development computer.

Getting Started

To get started, you need to install Visual Studio 2005 Tools for Office (included with Visual Studio 2005). Additionally, you need a separate download, Microsoft Visual Studio 2005 Tools for the Microsoft Office System, which contains core files to enable Outlook add-in support. It is recommended that you follow the instructions for system requirements and prerequisites provided on the download page.

When you install these files, the user interface shows that new templates have been added to your Visual Studio project templates (Figure 4).

Creating an Outlook add-in project

Figure 4. Creating an Outlook add-in project

In the New Project dialog box, the Outlook Add-in template is displayed with the other Visual Studio 2005 Tools for Office project templates, in the right pane. This template applies to projects developed in both Microsoft Visual Basic 2005 and Microsoft Visual C#.

To get going with your first Outlook add-in project, read the white paper, titled Visual Studio 2005 Tools for the Microsoft Office System, that accompanies the Microsoft Visual Studio 2005 Tools for the Microsoft Office System download.

For more information about the add-in architecture, see Understanding the Architecture of the Outlook Add-in Support in Visual Studio 2005 Tools for Office. This article elaborates on the design decisions and inner workings of the new Outlook add-in support feature.

To work with sample projects and sample code, see Visual Studio 2005 Tools for Office Sample: Outlook Samples. This download contains five sample projects that access different parts of the Outlook object model.

When you develop your Outlook add-in, you will find that you frequently use certain code declarations and routines. You can make the task of typing this code much easier by using five custom Microsoft IntelliSense code snippets, which target specific Outlook development tasks. To download the IntelliSense code snippets, see Visual Studio 2005 Tools for Office Sample: Outlook Snippets.

In addition, to gain practice experience with these samples and snippets, download Visual Studio 2005 Tools for Office Training: Outlook Hands-on Labs. This download contains six labs about developing in Visual C# and six labs about developing in Visual Basic 2005. Code examples accompany step-by-step instructions to help you learn more about add-in support and the Outlook object model.

Finally, to explore an end-to-end solution sample, see Creating an Outlook Task Add-in Solution with Visual Studio 2005 Tools for Office. This article and an accompanying code download step you through an explanation of a solution sample that integrates Outlook with Microsoft Office Word 2003, expansion packs, and WordProcessingML.

Conclusion

Until now, add-in developers who targeted Outlook faced time-consuming challenges. Debugging and deploying add-ins required numerous steps. With the help of new Outlook add-in support, developers can more efficiently debug, secure, and deploy the add-ins they create using Visual Studio 2005 Tools for Office. Outlook add-in developers no longer need to spend valuable time troubleshooting their design-time and deployment environments.

Additional Resources

For more information about Outlook add-in tools, see these resources: