Siew Moi Khor, who is an awesome contributor to the Office development community, points this out about the shim approach:

“Using the shim also means the config file can be placed in the same directory as the assembly, instead of the office app directory. 

But even with separate appdomains, developers might find they would still need to do some ReleaseCOMObject.  That was the case we found with managed smart tags using the VSTO loader.”

Although you might have to call ReleaseCOMObject for some scenarios, the thread she attached to this e-mail points out another advantage of using a shim to load your add-in into it's own appdomain--if you end up doing the dreaded “ReleaseCOMObject in a while loop” trick, you will only affect your own runtime callable wrapper and not those used by add-ins in other appdomains.  This is goodness.

BTW--creating managed smart tags using the VSTO loader is a little known feature of VSTO 1.0.  You can read more about this in the smart tag SDK ( but the short story is that if you use this technology, you don't have to write a shim--you can get the “in my own appdomain” behavior for free.  You also get the same security model used by VSTO 1.0.