It has been a while since I have blogged. I figured I would share my experience on developing a Managed Code Outlook add-in.

It all began about a year ago when I was a member of my company's R&D team. Yep, I was a Software Architect before venturing into management (maybe will share some more on this topic on another blog entry). We were asked to build an Outlook plug-in to pull down customer information from our CRM/ERP system.
They required all the good jazz from sending emails, creating distribution list, importing customers to the contacts folder to syncronizing customer information (that was a feat).

Believe or not though, that was the easy part. Building the functionality was a piece of cake. Heck, even using the maze-like Outlook Object Library (version 11) was somewhat like a walk in the park.
What was so annoying and time consuming was the fact that if you (heaven forbid) opened a form in design view VS.net would choke when it came time to build. I would keep getting a silly "COM Interop Registration Failed". I would have to quit and restart VS.net each time.

Could you imagine having to work in those circumstances? So, a few weeks into the project I was ready to package the app, install it on some training machine and demo it to the execs. Easy stuff right? - Think again. While the sucker worked fine on my development machine, it would not run when installed on others. Keep in mind that the Set-Up project was created by VS.net add-in wizard - I did nothing, nor was I supposed to. The install routine would finish smoothly.

The app would show in the Add/Remove programs, but it just would not load with Outlook! Apparently this is because one of the following reasons: (From: Omar Shahine's WebLog)

1. Another add-in is installing the Office 2003 Primary Interop Assemblies in their own application directory.
2. Another add-in is using a private version of the Office XP Primary Interop Assemblies that conflicts with the version that you are loading. Depending on an number of factors, your assumption that the set of assemblies you targeted will not be loaded.
3. Another add-in installed a version of the Office PIAs in the GAC that are incompatible with yours, or, are getting loaded in place of the assemblies you targeted.
4. Another add-in is calling Release COM Object and you are getting hosed (see http://blogs.officezealot.com/whitechapel/ for even more info on the subject).
5. Some other reason that I am sure exists and I am not aware of.

You have no control - really!!!

So, given these things it seems to me that it's really difficult to have a lot of control over your deployment given the eco system for managed add-ins out there. Bottom line, other products and add-ins can invariable affect you whether you like it or not. The only sure way to protect yourself is to implement a shim as outlined in this article.

Initially I tried to convince myself that there must be a way! After days of messing with it I found NO WAY! I implemented the C++ shim and finally got the install to work.   One word of caution - it was not a simple task, so I am not even going to go into the detail of how it is done. All I can say is that there was a lot of coffee involved and a really long night.  

Microsoft to the rescue!

Well yes, wouldn't you know it! Years of having to deal with $%@! Microsoft finally decided to help us out. Microsoft dealt with all my issues (and lots more) with the upcoming release of Visual Studio.net 2005 and the .net 2.0 framework. It's callled VSTO - Visual Studio Tools for Office -- take a look here

Conclusion

Even though I had a heck of time building this Add-in, I am pleased with the experience and knowledge that I gained from hashing it out. Trust me, I have built some serious software in my past, but this little add-in made me work for my money. Furthermore, I am pleased with Microsoft for having realized that the product needed help and actually admitting to the fact that the whole COM Add-In thing was dodgy to say the least. Kudos to Microsoft. If you are building an Outlook Plug-In and stunbled on this blog while trying to find some solutions, I can suggest you visit http://www.outlookcode.com/  Sue Mosher is an expert Outlook programmer and runs the site from her Washington DC metro area office.