Condividi tramite

Programming for Outlook using managed code is better with a Shim

  • Articolo

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:

  1. It was unfamiliar territory.
  2. I don't know C++ and was afraid I'd encounter a problem I could not solve.
  3. I had philosophical problems going this route.

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.

  1. Read the step by step overview.
  2. Read Dan's post.
  3. Download the Shim bits in step 1.
  4. Follow all the steps in the article from step 1.
  5. Strong Name sign your add-in.
  6. Add the Shim project to your Solution.
  7. Build
  8. Test to make sure that your add-in loads
  9. Authenticode Sign the Shim

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.

  1. Remove all the current project output
  2. Add the Authenticode signed unmanaged shim as an assembly and mark it for vsdraCOM and then add the assembly from your managed shim (from bin/Release).

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.

Comments

  • Anonymous
    May 22, 2004
    Cool. A question though, perhaps a little off topic, but is there a similar way to write Entourage add-ins or general Office add-ins for Macintosh OS X Office? I know there is the VBA route, but anything else? Perhaps a soulution using AppleScript?

    thanks,

    r.S.
  • Anonymous
    May 23, 2004
    Entourage has great AS support, as does Word 2004.