As has become customary, Microsoft saves some of the best news related to their development tools for the annual Tech-Ed conference. Among the big news items this year was the announcement that the upcoming release of Visual Studio 2005 Team System will include extensions for Outlook 2003. With the new Visual Studio Tools for Office (VSTO) extensions, building an Outlook add-in with managed code will be a straight-forward exercise in coding productivity.
Developers have had the ability to create Office add-ins since Visual Studio was released, but the move from a COM-based approach to a .NET-based approach has been difficult, largely due to the fact that Office is still a COM-based technology. Given this, perhaps the biggest hurdle to add-ins building with managed code is the deployment issue. Once you have completed the coding your add-in, to properly deploy a managed add-in you must also build a "shim" to act as a proxy between the add-in and Office. This shim is really just a native-code wrapper that handles the task of initializing the managed add-in at run-time.
(For a full discussion of the Shim solution, including both a high-level overview and the deep technical details, read "Using the COM Add-in Shim Solution to Deploy Managed COM Add-ins in Office XP")
The Office 2003 security model drives the need for the shim workaround. In a conservative environment where security settings are set to high and add-ins are not trusted by default, an add-in must be signed before it will run on a user's system. No problem right? Just build the add-in and use Authenticode to sign the add-in's assembly and everything is golden right?
Wrong-O!
The reason is that all managed add-ins load within the same application domain created by mscoree.dll (the file containing the core .NET functions). It is mscoree.dll that performs the task of loading the managed add-in's assembly. And it is mscoree.dll that would need to be signed to satisfy the COM-based method of code signing and security. This is not a good strategy as signing mscoree.dll would allow any managed add-in to run on the system.
The shim solution alleviates this problem and provides a "loader" that will only load the desired add-in. In addition, the shim can be signed to comply with the needs of Office 2003 security.
VSTO-OutlookCool Stuff
After you create your first Outlook add-in using Visual Studio Tools for Office, you may wonder just what's the big deal, as, at a high level, only a couple of small differences exist between a VSTO-based add-in and the managed add-ins already available in Visual Studio. For example, the stubbed-out code only has two events (Startup and Shutdown) versus the five events available in a managed add-in. That's fine if this is all you notice, but don't be fooled into thinking the changes to your Outlook development efforts are small. Let's look at three of the main benefits of a VSTO-Outlook add-in.
VSTO Handles Project Setup: VSTO not only creates the classes that implement the IStartup interface required by the add-in, it also implements the shim required to interface managed code with Office. The key here is that you, as the developer, do not have to implement the shim yourself. This is a big time saver.
Two Events: IStartup removes the confusion involved with IDTExtensibility2. With IStartup, only two events are involved… one for Outlook's startup and another for Outlook's shutdown. Now you no longer need to wonder when to use the old favorites of OnConnection, OnStartupComplete, OnDisconnection, and OnBeginShutdown. Just put you initialization code in the Startup event and cleanup after yourself in the Shutdown event and save yourself some wrinkles.
Security is now .NET-based: Stop straddling the divide that separates Office security and .NET security. Outlook VSTO add-ins fall under the .NET Code Access Security Policies just like all .NET code. Therefore, your VSTO-based Outlook add-ins only need to be granted Full Trust in CAS to execute. There is no need to deal with Office security.
A Quick Example
Using the new VSTO-Outlook project templates, I was able to build a simple but useful Outlook add-in. This add-in automates one step of a workflow I use to clear out my Inbox. I like to keep my inbox relatively empty because a cluttered Inbox makes finding items difficult and requires too much of my brainpower to keep track of which emails need follow-up. So instead of allowing emails to pile up, I read them and then create a TaskItem, an AppointmentItem, or a NoteItem. What type of item I create depends on what type of follow-up is required and what type of information the email contains.

Figure 1. My Simple Email Addin displaying the convenience menu
|
After I select an email, the add-in searches my default contacts folder for a ContactItem with an email matching the sender's email (the add-in checks all three email address fields). If it finds a match, the add-in displays a "convenience" menu with four buttons. These buttons allow me to create a Task, Appointment, Note, or Contact item that is linked to the matched contact record (see Figure 1).
Using the displayed convenience menu, I can now quickly create Outlook items (Tasks, Appointments, Contacts, and Notes) associated with their related Contact. Download the source code for this article to see how easy it is to build a useful Outlook add-in.
VSTO has already proven it is a powerful and worthwhile technology for building business solutions on top of Office. The release of VSTO support for Outlook means that Outlook will only continue to move to the forefront as a smart-client user interface for business applications.