Lately, I’ve been doing some work with integrating some of my managed applications with Outlook. There are a lot of code examples and articles out there on using the Outlook COM interop library for tying into Outlook, but be prepared for a lot of security prompts for the user. I understand the reasoning behind those security prompts, but man are they annoying.
You basically have two options at this point if you don’t like the prompts. Extended MAPI or Outlook Redemption. Seriously, those seem to be the only two options available, unless your application is actually an add-in using VSTO. Extended MAPI is essentially the low-level side of Outlook. To program against it, you’re looking at using C/C++ or Delphi, because your only interface is header files. I took a look at it and it is HAIRY. If you are interested in that option, though, check out MAPIEx at the Code Project. It has some great examples of using Extended MAPI and also showed me enough to scare me away from this option. I would love to spend my company’s time and resources learning this and code in C++, but I don’t think they would appreciate that very much.
Okay, next. Outlook Redemption. It is a COM wrapper around the Extended MAPI interface that works great. Dmitry Streblechenko created a lot of safe objects around their Extended MAPI counterparts. You code against the Outlook Interop library (add a COM reference to “Microsoft Outlook 11.0 Object Library”) and tie that in with Redemption. Everyone uses this thing. Just about every newsgroup post, website, etc. that mentions tying into Outlook recommends this library. I guess this is another recommendation.
My only real complaint with Redemption had to be the stupid Fields collection off of just about every Redemption object. For example, let’s look at the
Redemption.AddressEntry. It exposes a name, address, and a few other handy properties, but that is about it. If you want to get anything else, you have to use the
Fields collection, which takes an
Integer and returns an
Fields collection could be compared to a Dictionary object in the .NET Framework. The name is a unique integer that is a lookup to a value. A little annoying but hey, if we have constants, who cares right? Right??? … What do you mean we don’t have any constants? Ohhh, we have to find those out for ourself or buy Outlook Spy! I hate magic numbers!
I was fairly confident that the lookup constants were defined somewhere so I began hunting them down and discovered the
MAPITags.h file (mine was at
C:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\Include). All of the constants use a macro called
MAPIDefS.h) that takes a
ULong propID and a
ULong propType. Internally, Outlook uses a multitude of different property types like
PT_BOOLEAN, etc. The
PROP_TAG macro takes the type and a unique lookup. That’s why the
Fields dictionary returns an
Object: it might be a long or a boolean or a string or an internal Outlook structure. I ended up writing a console application that read in a header file and spit out a list of VB constants. The regular expression I used was
Anyway, long story short, I’m working with Outlook now and it is really cool. I’m able to, based on a name and my generated VB constants, lookup a property of a contact in my address book. Another programmer and I have been
spamming each other testing with meeting appointments and emails ever since. Fun, eh?