Every once in a while, it’s nice to let off steam and blog about a project you’ve been working on for the past few months.  Well, it’s my turn and the project in question is a prototype I’ve been working on with a number of customers and third party system integrators.  This is not related to any internal product in Microsoft, and not the beginnings of one - merely an exercise to see how flexible creating an object model in .NET can be.

 

Today, if you want to develop applications that integrate with Microsoft Outlook, you need to be fairly proficient in VBA, COM and/or MAPI.  Although there is the option within Visual Studio .NET to develop in a managed language and make calls into Outlook, the interface is effectively a managed wrapper over existing COM objects.  I wrote about my findings of doing this in an MSDN article in 2002.

 

Project Niobe is prototype code that abstracts the VBA, COM and MAPI layers into a single managed object model.  From here, you can develop applications that integrate with Microsoft Outlook using existing technologies, but develop against an object model that’s more in-line with the design of the classes and namespaces in the .NET Framework.

 

The easiest way to show this is with an example.  I want to create a new contact in Outlook and add this contact to my default contact folder.   Here is the code using Niobe:

 

using Niobe.Outlook;

 

Contact c = new Contact(“Bill”,”Gates”);

c.BusinessTelephoneNumber = “425 123 4567”;

ContactFolder.DefaultFolder.Add(c);

ContactFolder.DefaultFolder.Save();

 

In addition to creating new objects, the object model also allows you to handle existing events from within Outlook.  For example:

 

TaskFolder.DefaultFolder.ItemAdded += new ItemEventHandler(DefaultFolder_ItemAdded);

... 

private void DefaultFolder_ItemAdded(Item item)

{

     Task newTask = (Task)item;

     MessageBox.Show("Lets make a Web Service call and tell it about this new task: "+

                      newTask.Subject);

 

     // imagine a call to a web service that passed this task as a parameter

}

 

Finally, objects can expose their data in various ways.  For example:

 

// To return a strongly typed dataset containing the contents of your default contact folder:

ContactFolder.DefaultFolder.ContactsAsDataSet

 

// To iterate through a folder containing contacts and display location

foreach(Contact c in ContactFolder.DefaultFolder)

{

            MessageBox.Show(c.FullName+“, “+c.City+“ “+c.State);

}

 

So, while this all looks like Office programming nirvana, let me remind you that there are of course some caveats.  Niobe is called a prototype for good reason.  It’s unsupported, will never be released, and has its fair share of bugs and feature requests.  I’m hoping that by posting it as a GotDotNet workspace (which you can check out at http://workspaces.gotdotnet.com/niobe), other developers that are writing applications that integrate with Outlook can maybe learn from some of the approaches that have been taken.

 

Looking to the future, it's clear that the advantages of WinFX, WinFS and centralized schemas will undoubtedly provide a new way of accessing data - and will replace some application-based APIs.   Until we are able to take advantage of this new technology however, this project has shown some interesting possibilities with today’s version of Outlook.