More ReleaseCOMObject

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 (https://www.microsoft.com/downloads/details.aspx?familyid=c6189658-d915-4140-908a-9a0114953721&displaylang=en) 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.

Comments

• Anonymous
  April 16, 2004
  or Would You, Could You in the Rain? I thought Id try to round off the discussion with a simple summary Two questions: 1 Under what circumstances would you (want/need to) RCO? 2 Under what circumstances could you (safely) RCO? Some Answers: 1 Under what circumstances would you want/need to RCO? 1.1 When your RCW is proxying a COM object thats holding onto a lot of memory or other resource that you need to release eagerly (for performance or contention reasons). 1.2 When you believe a circular reference has deadlocked and you want to break the cycle. 1.3 When your...