This project has moved and is read-only. For the latest updates, please go here.

Finalizer in COMObject?

Apr 10, 2012 at 5:23 PM

Hello -

First off, I wanted to say thanks - this is a very useful framework!

Now, my question: is there a reason why the COMObject class doesn't have a finalizer? It seems like using the finalizer/dispose pattern would provide a good "failsafe" for instances where someone forgets to dispose an object. Are there other factors that could make it a bad idea? Or maybe it's taken care of somewhere else and I just missed it?


Thanks again,

Sebastian C.

Apr 10, 2012 at 7:40 PM
Edited Apr 10, 2012 at 7:45 PM


do you the COM Proxy management concept in NetOffice?
the current documentation is small and could be better:
i create new tutorials and examples at the moment. a finalizer is a good idea, i need some tests to verify the idea works well with COM Interop but i think it doesnt works. a problem with the finalizer is you have no control the finalizer is called or not and also the calling time and you have no control about the calling order. this means:

Excel.WorkSheet sheet = app.ActiveSheet;
foreach(ExcelRange cell in sheet.Range("A1:A100))
sheet.Dispose(); // all proxies destroyed now

we have 102 ComProxies created here. the Sheet, the Range enumerator and 100 cells. NetOffice store the proxies in a special tree for you.

- sheet
    -range enumerator
        - cell
        - cell
        - cell

if you dispose an object then all created child proxies are disposed now, in a reverse order from creation.
in our sample sheet.Dipose() calls dispose for the 100 cells first, now the range enumerator and as last himself.
this reverse release direction is important, otherwise a COMException was thrown in some situations "Parent proxy is being released from the COM Server" maybe the garbage collector calls the finalizer for the application first and as next step the other proxies. a limitless exception party...