Ok, recently I posted an article titled: Programming for Outlook using managed code is hard. This article summarized and documented some of the pain that I experienced in writing my Outlook2OneNote Add-in.
All this time I was aware that there was another route I could take, one that Dan Crevier did a great job explaining in a recent post. Originally I didn't want to go the Shim route because:
Luckily Dan helped me with #1 and #2, and well, I got over #3. I mentioned that I had been working with some MS folks that are domain experts in this area and they have always suggested that the Shim route was best. Rather than go with their expert advice I went and suggested that people do something that was explicitly unsupported (targeting the Office XP Interop Assemblies rather than the 2003 Primary Interop Assemblies).
Now, for one thing it's not good for me to be offering you unsupported solutions if there are better solutions out there. Secondly, there are some benefits to the Shim route that you won't get otherwise. With a Shim you get your own AppDomain and if you Authenticode Sign the Shim, and Strong Name sign the managed add-in you will not get the Outlook Security prompt when accessing e-mail fields like body. The net result is that you will be in a situation that you have more control over, offers a better user experience, and protects your add-in.
The only downside to this is that you still have to rely on the user successfully installing or having access to the Office 2003 PIAs. It's unfortunate that there is no redistributable version of the 2003 PIAs, but the good news is that for the majority of users, they should be automatically installed when your add-in first loads.
So starting with Outlook2OneNote working against the XP Interop Assemblies here is what I did to get the Shim working.
You no longer need to keep building the Shim as you have a signed DLL that has the public key of your managed add-in to load in outlook. You just need to ensure that you register the assembly if you are debugging and make sure it's located in the same directory as the managed dll (/bin/Debug).
Now you also need to make changes to the Setup project.
I would like to thank Misha Shneerson, Siew-Moi Khor, Art Leonard and Andrew Cherry for helping me do this the “right way” and helping me debug some of the problems.