Can I get some clarity on ReleaseComObject? Can I ignore it?

Question

I have been developing office solutions in VBA for a while now and have fairly complete knowledge regarding office development in VBA. I have decided it is time to learn some real programming with .Net and am having some teething problems.

Having looked through a bunch of articles and forums (here and elsewhere), there seems to be some mixed information regarding memory management in .Net when using COM objects.

Some people say I should always deterministically release COM objects and others say I should almost never do it.

People saying I should do it:

The book 'Professional Excel Development' on page 861.

This stack exchange question has been answered by saying "every reference you make to a COM object must be released. If you don't, the process will stay in memory"

This blog suggests using it solved his problems.

People saying I should not do it:

This MSDN blog by Eric Carter states "In VSTO scenarios, you typically don't ever have to use ReleaseCOMObject."

The book 'VSTO for Office 2007' which is co-authored by Eric Carter seems to make no mention whatsoever of memory management or ReleaseComObject.

This MSDN blog by Paul Harrington says don't do it.

Someone with mixed advice:

Jake Ginnivan says I should always do it on COM objects that do not leave the method scope. If a COM object leaves the method scope then forget about it. Why can't I just forget about it all the time then?

The blog by Paul Harrington seems to suggest that the advice from MS has changed sometime in the past. Is it the case that calling ReleaseCOMObject used to be best practice but is not anymore? Can I leave the finer details of memory management to MS and assume that everything will be mostly fine?

Answer 1

I try to adhere to the following rule in my interop development regarding ReleaseComObject.

If my managed object implements some kind of shutdown protocol similar to IDisposable, I call ReleaseComObject on any child COM objects I hold references to. Some examples of the shutdown protocols I'm talking about:

• IObjectWithSite.SetSite(null)
• IOleObject.SetClientSite(null)
• IOleObject.Close()
• IDTExtensibility2.OnDisconnection

• IDTExtensibility2.OnBeginShutdown

• IDisposable.Dispose itself

This helps breaking potential circular references between .NET and native COM objects, so the managed garbage collector can do its job unobstructively.

Perhaps, there's something similar which can be used in your VSTO interop scenario (AFAIR, IDTExtensibility2 is relevant there).

If the interop scenario involves IPC COM calls (e.g., when you pass a managed event sink object to an out-of-proc COM server like Excel), there's another option to track external references to the managed object: IExternalConnection interface. IExternalConnection::AddConnection/ReleaseConnection are very similar to IUnknown::AddRef/Release, but they get called when a reference is added from another COM appartment (including apartments residing in separate processes).

IExternalConnection provides a way to implement an almost universal shutdown mechanism for out-of-proc scenarios. When the external reference count reaches zero, you should call ReleaseComObject on any external Excel objects you may be holding references to, effectively breaking any potential circular COM references between your process and Excel process. Perhaps, something like this has already been implemented by VSTO runtime (I don't have much experience with VSTO).

That said, if there is no clear shutdown mechanism, I don't call ReleaseComObject. Also, I never use FinalReleaseComObject.