Trying to deploy an Outlook add-in

Even us grizzled security professionals occasionally have to give up when faced with a pile of security so incomprehensibly bizarre as to make life seem impossible.

Recently, a member of our Security Council asked the simple question “instead of having us manually forward email to the junk mail filters, can we have a button that automatically forwards our currently selected messages as false negatives?”

When I heard of this, my natural inclination was “sure, I’m not doing anything terribly interesting or important with my few minutes of spare time a day – how hard could it be?”

I should slap myself every time I say “how hard could it be?” – although this phrase has often brought me my best achievements (WFTPD came from “this piece of crap FTP server [WinQVT/Net] crashes every time a second user logs on – how hard could it be to write a working FTP server?”), it’s also brought on some of the hardest challenges. WFTPD took a solid six months before it was remotely usable, and a few years to get to its current state, including a three month period just trying to get SSL working.

In this case, of course, I said “how hard could it be – looks like it’ll be really easy in .NET”.

So, I spent two hours writing the add-in in C# .NET.

And the following three weeks trying to figure out how to deploy it.

There were pre-requisites and requirements, updates to install, KB article patches to fetch, and then I had to write or download an extra setup custom action to add my add-in to the Code Access Security using CASPOL.EXE.

Yuck. I mean, don’t get me wrong, CASPOL’s a wonderful idea – that you can list what behaviours a program is allowed to have, that’s really powerful. Unfortunately, it’s also difficult, and prone to making it so difficult that the whole project got canceled.

Fortunately, I’m not a one-trick pony. I canceled the .NET project, sure, but I got to looking at Microsoft’s Outlook Junk Mail button – Steve Riley pointed it out recently – and I noticed that it’s written as a straight COM component using C++.

So I do the same. It’s slightly longer to develop – perhaps six hours, because I’m really not familiar with COM, and I make a few beginner mistakes. But to deploy – it’s a simple case of copy the file, run regsvr32, and away we go – a perfectly operating (if possibly a little unsecure) Outlook add-in.

Can anyone tell me why I should have persevered with the .NET version?

Or better still, how I should have done it more easily?

3 thoughts on “Trying to deploy an Outlook add-in”

  1. I feel your pain. I just did a google search on “Why the hell is it so difficult to install an outlook add-in” and found your page. Dagnamit.

  2. Haha, exactly the pain the pain… and yes i wrote that twice, im writing an add-on to deploy in outlook 2007 and also outlook 2010 with seperate code bases but one install package… the agony im suffering from as part of this is hooooooooj!

  3. Build the solution that has the add-in

    publish the solution to a local drive (the CD or DVD option, not the UNC or Internet)

    Copy that entire (newly created) folder to the target machine where you want to install

    Double click setup.exe within that folder.

    The outlook add-in is now installed.

    Much more information here:

Leave a Reply

Your email address will not be published. Required fields are marked *