Release COM Components

Is it really necessary to release COM components from Office PIA when you no longer need them by calling Marshal.ReleaseComObject (..)?

I found various and conflicting tips on this topic on the Internet. In my opinion, since Outlook PIA always returns new links to its interfaces as returning values ​​from its methods, there is no need to explicitly release it. I'm right?

+4
source share
8 answers

In Microsoft Office, in general, you need to explicitly publish your links, which can be safely completed in two steps:

(1) First, release the entire minor object, to which you do not hold the named variable of the object, by calling GC.Collect (), and then GC.WaitForPendingFinalizers (). (You need to call this twice if the objects involved can have finalizers, for example, when using Visual Studio Tools for Office (VSTO).)

(2) Then explicitly free the objects to which you are holding the named variable by calling the Marshall.FinalReleaseComObject () object for each object.

What is it.: -)

I discussed this in more detail in a previous post , as well as sample code.

+1
source

PIAs are .NET interop wrappers. This means that in the object's destructor (or Dispose - I don’t remember) it will automatically process the reference count. The trick is that some links will not be released until the garbage collector is executed. It depends on what the COM object creates. For example, a COM object that opens database cursors will store these cursors in memory until a reference counter to these cursors is released. Using .NET / COM interaction, links are not displayed until the garbage collector executes or you explicitly publish the link using Marshal.ReleaseComObject (or FinalReleaseComObject).

I personally have not worked with PIA Microsoft Office, but in most cases you do not need to explicitly release links. It is only when your application starts blocking other resources or a failure that you should start to suspect broken links.

EDIT: If you are faced with a situation where you need to clear COM / Interop objects, use Marshal.FinalReleaseComObject, which translates the reference count to zero, and not just decreases by one - and set the reference to the object to null. You can explicitly force the garbage collection (GC.Collect) if you really want to be safe, but be careful with the GC too often, as this causes a noticeable performance hit.

+2
source

There are some good practices here with guided wrappers..worth checking ..

+1
source

Perhaps this is just my superstition, but I decided to explicitly publish Office PIA through Marshal.ReleaseComObject (), because when my application crashed, the links to Excel and Word remained open. I did not think too deeply about why (silly terms), but releasing them as part of my class eliminates the pattern that fixes this problem.

0
source

You need to do this if you want an instance of the Office application to exit as described in this post .

And it's hard to do it right in all but the simplest scenarios.

0
source

My experience shows what you need, otherwise (at least Outlook) the application may not close at all.

But this opens up another possibility for worms, since it is similar to RCW for each process, so you can break another addon that happens to have a link to the same object.

I posted a related question here , but I still don't have a clear answer. I will edit this post as soon as I learn more.

0
source

There is one simple rule about .Net / COM communication. When in doubt, always Release (). :-)

0
source

Source: https://habr.com/ru/post/1277441/


All Articles