Feature

Digg This!

Page 2 of 2   « previous page

Processing Calendar Events
The CalendarProcessing class handles all of our add-in's heavy lifting. It hooks into the Outlook event model to get notified of any calendar changes and pushes changes from the "client" Exchange server to our main Exchange account. To respond to changes to items on the calendar, we need to sink the notification events exposed by Outlook. As Listing 2 indicates, this too is pretty straightforward. Once we're getting notified of changes to our calendar from Outlook, we need to respond to them by adding, updating or deleting calendar items on the target Exchange server as appropriate using WebDav.

Using WebDav to talk to Exchange over HTTP can be a daunting task because of the complexity and amount of code required to handcraft the HTTP calls. Fortunately, there are third-party products that encapsulate this into simple object-oriented calls. One such product is IndependentSoft's WebDav .NET for Exchange (www.independentsoft.de/webdavex/index.html). WebDav .NET for Exchange is a managed assembly that exposes objects and methods for making calls to an Exchange server over WebDav. With WebDav .NET for Exchange, adding calendar items to a remote Exchange server is as easy as setting some properties and calling a method.

Adding new calendar items is simple: Get the details of the new calendar item and create a new calendar entry on our target Exchange server with the same data (subject, start time, end time, etc.) using WebDav. In code, we do this using the ItemAddHandler that we set up earlier. Since WebDav .NET for Exchange expects an instance of an IndependentSoft appointment as a parameter and we're working with an instance of an Outlook appointment, we simply need to map the properties from the Outlook appointment to the IndependentSoft appointment (see Listing 3). Note that after each item is added to the remote Exchange server, we'll write an entry to a cache containing the calendar item's EntryID plus some other data about the appointment. We do this so we can permanently map the item on the "client" Exchange server to an item on the target Exchange server. We also persist the cache to a file so we have access to it next time we run Outlook. It's important to do this because without this cache we wouldn't be able to update the target server if a calendar item changes on the "client" Exchange server.

Updating calendar items is a little more difficult because we have to map the changed item on our "client" Exchange server to an existing item on our target Exchange server. To do this we have to read from our cache to get a handle on the calendar item on the remote server. Once we have this, we can use WebDav to update the item on the remote server. We also have to update our cache to make sure it references any changes we made. Listing 4 shows the code for updating an existing calendar item.

Deleting calendar items presents the biggest challenge in our add-in. The reason is that the deleted item handler exposed by Outlook doesn't pass the item that was deleted as a parameter. Because of this, there's really no good way to use the deleted item handler to track deleted calendar items. Instead we'll link the ItemAdd handler on the Deleted Items folder. This gets called when any item (not just calendar items) are added to the Deleted Items folder. We just have to add a check in our event handler to ignore items that aren't calendar items. Other than that, we can use the same logic that we used for updating calendar items: Search the local cache for a handle to the remote item and make a WebDav call to delete the remote item. All of this is show in Listing 5.

These three functions make up the core logic of the entire add-in. As items are added, changed, or removed from the "client" Exchange server through Outlook, our code is triggered to add, change, or remove the item from the target Exchange server. Now the target Exchange server always contains up-to-date calendar information. With very little work, the functionality presented here can be extended to other Exchange items, such as e-mails and tasks. Adding additional features such as filtering which items are synchronized would be very easy.

Deploying Our Add-In
One of VSTO goals was to make deploying Office extensibility applications simple. When creating a new Office project, Visual Studio automatically created a Setup and Deployment project for you. Unfortunately Microsoft didn't do a good job delivering on the goal of easy deployment with VSTO. There are three main problems with its deployment process:

1. The deployment project doesn't install the VSTO runtime on the target machine. If the machine where you're installing the add-in doesn't have VSTO installed, then the add-in won't load.
2. The deployment project doesn't install the Outlook 2003 Primary Interop assemblies. This is required to run the add-in.
3. FullTrust isn't granted by default on the add-in assembly, meaning the add-in won't load in Outlook because the new model for managed add-ins requires that FullTrust be granted to the assembly.

All of these can be worked around, but it would have been nice for Microsoft to nail this out-of-the-box. For numbers 1 and 2, it's simply a matter of manually adding these as dependencies to your deployment projects. Both the VSTO runtime and the Outlook 2003 PIA can be downloaded free from Microsoft at www.microsoft.com/downloads/. For code access security, you have a couple choices. One option is to write your own installer class to programmatically grant full trust to your assembly when it's installed. A partial example of this is shown in Listing 6. The other option is to use the caspol.exe tool and grant trust to the application on the target machine after it's installed.

Conclusion
With new project templates to get you started and the integrated debugging capabilities of Visual Studio, Visual Studio Tools for the Microsoft Office System greatly improves developer productivity when writing Office extensibility applications, especially Outlook add-ins. VSTO's AddinLoader component hides the complexities of writing managed add-ins for Microsoft Outlook without requiring any changes to the Outlook binaries. Deployment isn't as easy as it should be, but once you know the issues, it's easy to work around them.

Page 2 of 2   « previous page