Managing calendars across multiple Microsoft Exchange servers has always been a problem for those of us in consulting or other professional service fields. Having to aggregate appointments across calendars maintained at multiple client sites, plus your calendar back at the home office - and potentially even an Exchange calendar at home - is particularly cumbersome. Manually consolidating your calendars is time-consuming and error-prone - it only takes a couple of missed or double-booked appointments before you realize that there has to be a better way.

In this article we'll show you how to use Visual Studio 2005 Tools for the Microsoft Office System (VSTO) to write a Microsoft Outlook add-in that automatically aggregates free/busy information across multiple Exchange servers. In doing so we'll dig into the details of the much improved event model exposed by VSTO for integrating with the Office suite of applications. The new simplified add-in interface is much more reliable than the old IDTExtensibility2 interface and greatly reduces the time it takes to get your application off the ground. We'll also discuss how VSTO together with the Visual Studio 2005 IDE make coding and debugging your Outlook application a breeze. Finally, no discussion of Outlook add-ins would be complete without addressing deployment: getting your add-in into the hands of end users. We'll explore the tools and techniques (as well as a few gotchas) that you need to know to distribute your completed application.

What Is VSTO?
VSTO is a developer's toolkit providing a simplified interface, a built-in "AddInLoader" component, and integrated debugging capabilities that make writing Office add-ins as easy as writing Windows Form applications. Visual Studio 2005 and VSTO make it easier than ever for developers to build managed applications that integrate with and extend the Microsoft Office suite. While VSTO offers benefits for developers targeting most of the applications in the Microsoft Office suite, this article will focus only on building add-ins for Outlook. However, there are quite a few articles and samples on programming Word, Excel, and other Office products on the Visual Studio Tools for Office web portal at http://msdn.microsoft.com/office/understanding/vsto/.

Microsoft did a great job of focusing VSTO on the areas of Outlook extensibility that needed it the most: Tighter integration with Visual Studio, a simplified integration interface, better debugging capabilities, and easier deployment. VSTO offers all these things.

Integration with Visual Studio
With VSTO, starting an Outlook add-in project is easier than ever. VSTO introduces a series of new project types for creating projects that extend Microsoft Office. These include project templates for creating Excel workbooks, Word documents, and Outlook add-ins (see Figure 1). Selecting the project type of Outlook add-in will create a shell project for your add-in, plus a setup project for deployment. You're then ready to code your add-in.

Simplified Interface
In past versions of Visual Studio, the interface IDTExtensibility2 was the proper way to hook into Outlook and get at the Outlook object model. VSTO replaces the IDTExtensibility2 interface for a much simpler approach - the IStartup interface. IStartup exposes just two very clearly named events: Startup() and Shutdown(). When you start a new project using the Outlook add-in template, Visual Studio inserts event handlers for these two events as follows:

Private Sub ThisApplication_Startup(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Startup

Private Sub ThisApplication_Shutdown(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Shutdown

Contrast these with the five ambiguous events exposed by IDTExtensibility2, OnConnection, OnAddInsUpdate, OnStartupComplete, OnBeginShutdown, and OnDisconnection. If you ever wrote an add-in using IDTExtensibility2, you know that the events did not regularly fire, and it wasn't clear by the event name when exactly you should expect the event to fire, or even what you should do in the event handler. As we'll see below, all of this is much easier with IStartup's two simple events.

Improved Debugging
VSTO handles all of the plumbing to hook into Outlook and gives you "F5 debugging" of Outlook add-ins. What this means is that you simply write your code and press F5 to run. VSTO will automatically start up Outlook, hook up your add-in, and start executing your code. You'll get all of the rich debugging features of the Visual Studio IDE (break points, watches, call stacks, etc.) without having to do anything different than you'd do with any other Visual Studio project.

As a developer, you're completely shielded from the underlying complexity of loading your managed add-in into Outlook's unmanaged address space. You don't need to worry about COM+ bridges, shims, or any other techniques thanks to VSTO's new AddInLoader component. The AddinLoader is the VSTO component for loading and unloading managed add-ins to and from Outlook's address space.

The AddinLoader does the following tasks:

• Sets up a dedicated AppDomain for your add-in. Because your add-in runs in its own AppDomain, it's isolated from other add-ins and from the VSTO runtime itself.
• Checks permissions (using Code Access Security) on the add-in assembly to ensure it has FullTrust permission. If not, the AddinLoader won't load the add-in.
• Proxies the calls from the IDTExtensibility2 interface to the IStartup interface.

The AddinLoader is an unmanaged COM component that implements the IDTExtensibility2 interface and serves as a proxy to VSTO's new IStartup interface. Because of this, VSTO can operate on top of the existing Office components without requiring any changes to the Office binaries (remember, Outlook natively requires add-ins to support IDTExtensibility2). As Outlook makes calls to the IDTExtensibility2 interface, VSTO's AddinLoader component proxies the calls to the appropriate IStartup interface method.

To run the sample code included with this article, you'll have to install VSTO. If you have an MSDN subscription, you can download a copy of VSTO. You can also download a trial copy of VSTO from Microsoft at http://msdn.microsoft.com/vstudio/products/trial/.

Synchronizing Exchange Calendars
If you use more than one Exchange account you probably already know how difficult it can be to coordinate updates to multiple calendars. For example, you may have an Exchange account at a client and an Exchange account at your home office. With multiple calendars, ensuring that you have a single place to go to check your agenda can be tricky. Let's see if we can use VSTO and Visual Studio 2005 to solve this problem.

Using VSTO we can build an add-in that hooks into the Outlook object model and listens for calendar events. This allows us to detect changes to our calendar from one Exchange account - we just need a way to push the changes to the calendar in our second Exchange account. To do that we'll use WebDav, a set of HTTP extensions that we can use to interact with an Exchange account on a remote server.

So our scenario looks like this: We have our home office Exchange account and our "client" Exchange account. The goal is to make sure the home office Exchange account accurately reflects any calendar items that exist on either Exchange account. To do this we'll install an add-in on the "client" Exchange account that listens for changes to its calendar and then pushes those changes to the home office Exchange server using WebDav.

Getting Started
As mentioned above, starting an Outlook add-in project is pretty straightforward. Simply fire up Visual Studio, start a new project, and choose "Outlook add-in" as the project type from the Office project templates. Visual Studio creates the shell for your add-in and automatically adds event handlers for both the Startup() and Shutdown() events. Visual Studio also creates a setup project for your add-in. The setup project builds a Windows installer file (.MSI) and makes deploying your add-in easier.

The Startup() event is used to initialize your add-in. It's called whenever your add-in is loaded into memory. For our add-in we'll do three things during startup:

• Create an instance of our Calendar-Processing class. This is the main class that handles all of the logic for processing and synchronizing calendar entries.
• Create an instance of our Settings class. This is the class that stores all of the configuration settings for the add-in.
• Add a menu item to the Outlook toolbar. The menu item is used to pop up the settings screen.

Our Startup() event handler is shown in Listing 1. This is all you need to do to initialize the application. All of the code to synchronize the calendar items is handled in the CalendarProcessing class. Note that once our Startup event has fired, we aren't really using any VSTO features anymore. From here on out, we're using the same Outlook object model that's always been available to us. VSTO, however, has helped quite a bit with the plumbing to get us to this point.