ReleaseCOMObject

Andrew Whitechapel has some interesting advise on using ReleaseCOMObject when writing managed code that automates office:  https://blogs.officezealot.com/whitechapel/. Andrew knows a lot about COM interop against Office and I trust what he says.

But I have to be honest and say that this advise completely terrifies me--especially the part about having to call ReleaseCOMObject in a loop, because as Andrew makes clear--if you do this you are a bad Office citizen if you are loaded in process with other add-ins. You may get your stuff to work, but you run the risk of breaking all other add-ins in the future. So don't do this please unless you are sure you are in your own process! That means you aren't using VSTO for example.

There are certainly times when you have to call ReleaseCOMObject--but you should really understand why and when you have to call it. Even more importantly, you need to understand when you *don't* have to call it.

In VSTO scenarios, you typically don't ever have to use ReleaseCOMObject. Why? Because VSTO starts your code up in its own appdomain and when the document associated with your code closes, VSTO unloads that appdomain which will also do the equivalent of an automatic ReleaseCOMObject for you on anything that appdomain was using. So I don't want to see any of y'all using ReleaseCOMObject in your code--unless you happen to be writing a VSTO customization in say Word that is automating PowerPoint. In this case, you might have to call ReleaseCOMObject on the objects you are referencing from PowerPoint to ensure PowerPoint shuts down properly (if the lifetime of Powerpoint is shorter than the lifetime of your customization and hence the appdomain we create for you). Otherwise, you shouldn't have to use ReleaseCOMObject if you are just using Word objects in a Word customization or just using Excel objects in an Excel customizations.

Many people have to use ReleaseCOMObject when they are building managed add-ins or smart tags. There's also a potential way to avoid using ReleaseCOMObject (which Misha--referenced below--pointed out to me) if you are using what is known in the business as a “shim”. There are various reasons why you might need a shim--mainly a shim is used when you need to run in an environment where add-ins must be signed and “Trust installed add-ins” is turned off. In this case, when Office expects all your add-ins to be digitally signed to run, it looks up your managed add-in in the registry (Office just thinks it is a COM add-in because it is not aware of managed add-ins natively) and when it looks up the inprocserver32 for the add-in it finds a .NET dll (mscoree.dll) which bootstraps the CLR into Office and then loads your actual add-in into the default appdomain. Well, the .NET dll (mscoree.dll) can't be digitally signed and thereby vouch for any arbitrary managed add-in that might get layed down on your machine. The shim approach allows you to put your own bootstrapper dll in that you can sign and thereby get around this issue. In addition, when you are building your shim, you can change the behavior to create and load your managed add-in into its own domain. Then when your shim gets a disconnect or shutdown message from Office, it can unload the appdomain it created, thereby making it so you don't have to call ReleaseCOMObject in your actual managed customization.

For more on shims, see these excellent articles by Misha Shneerson and Siew-Moi Khor:

https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnoxpta/html/odc_shim.asp and https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnoxpta/html/odc_comshim.asp

Comments

• Anonymous
  April 06, 2004
  Have you seen:
  http://samgentile.com/blog/articles/1987.aspx
  http://samgentile.com/blog/articles/294.aspx
  http://samgentile.com/blog/archive/2003/04/17/5797.aspx
  
  I have been writing on this issue for over 2 years. I am glad someone from Microsoft finally caught up
• Anonymous
  April 15, 2004
  I have a dream: That someone from microsoft will either do the research or publish existing research that provides best practices for the numerous scenarios that exist. I think this needs to be very formal and very detailed. I think there are a lot of wild questions and a diverse set of answers :-).
• 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...