Właściwy sposób zwalniania obiektów COM?

Question

Czasami, kiedy zakończyć aplikację i próbuje zwolnić niektóre obiekty COM, otrzymałem ostrzeżenie w debugerze:

RaceOnRCWCleanUp wykryto

Jeśli piszę klasy, która używa obiektów COM, czy muszę zaimplementować IDisposable i zadzwonić pod numer Marshal.FinalReleaseComObject w IDisposable.Dispose, aby je poprawnie zwolnić?

Jeśli Dispose nie jest wywoływana ręcznie, czy nadal muszę zwolnić je w finalizatorze, czy GC automatycznie je zwolni? Teraz I call Dispose(false) in the finalizer, ale zastanawiam się, czy to jest poprawne.

Obiekt COM, którego używam, ma również obsługę zdarzeń, której słucha klasa. Wygląda na to, że zdarzenie jest wywoływane w innym wątku, więc jak poprawnie go obsłużyć, jeśli zostanie zwolniony podczas usuwania klasy?

Answer 1

Na podstawie mojego doświadczenia z wykorzystaniem różnych obiektów COM (w trakcie procesu lub poza procesem) sugerowałbym jeden Marshal.ReleaseComObject na jedno przejście graniczne COM/.NET (jeśli dla instancji odwołujesz się do obiektu COM w celu pobrania innego Odniesienie COM).

Wystąpiłem w wielu kwestiach tylko dlatego, że zdecydowałem się odłożyć odświeżanie międzyoperacyjne COM do GC. Należy również zauważyć, że nigdy nie używam Marshal.FinalReleaseComObject - niektóre obiekty COM są singletonami i nie działa dobrze z takimi obiektami.

Robienie niczego w zarządzanych obiektach wewnątrz finalizera (lub usunięcie (fałsz) ze znanej implementacji IDisposable) jest zabronione. W finalizatorze nie można polegać na żadnych odwołaniach do obiektów .NET. Możesz zwolnić obiekt IntPtr, ale nie obiekt COM, ponieważ można go już wyczyścić.

Answer 2

Jest tu artykuł na ten temat: http://www.codeproject.com/Tips/235230/Proper-Way-of-Releasing-COM-Objects-in-NET

W skrócie:

1) Declare & instantiate COM objects at the last moment possible. 
2) ReleaseComObject(obj) for ALL objects, at the soonest moment possible. 
3) Always ReleaseComObject in the opposite order of creation. 
4) NEVER call GC.Collect() except when required for debugging. 

Do GC naturalnie występuje odniesienie com nie zostanie w pełni zrealizowany. Właśnie dlatego tak wiele osób musi wymuszać zniszczenie obiektów za pomocą FinalReleaseComObject() i GC.Collect(). Oba są wymagane dla brudnego kodu Interop.

Dispose NIE jest automatycznie wywoływane przez GC. Gdy obiekt jest usuwany, wywoływany jest destruktor (w innym wątku). Zazwyczaj jest to miejsce, w którym można zwolnić dowolną niezarządzaną pamięć lub odwołania do com.

destruktory: http://msdn.microsoft.com/en-us/library/66x5fx1b.aspx

... kiedy aplikacja obudowuje niezarządzanych zasobów, takich jak Windows, plików i połączeń sieciowych, należy użyć destruktorów, aby uwolnić te zasoby. Gdy obiekt kwalifikuje się do zniszczenia, śmieciarz uruchamia metodę finalizacji obiektu.

Answer 3

pierwsze - ty nigdy musiał zadzwonić Marshal.ReleaseComObject(...) lub Marshal.FinalReleaseComObject(...) robiąc współdziałanie Excel.Jest to mylący wzorzec antydopingowy, ale wszelkie informacje na jego temat, w tym pochodzące od firmy Microsoft, wskazujące na ręczne zwolnienie odniesień COM z .NET są niepoprawne. Faktem jest, że środowisko uruchomieniowe .NET i garbage collector poprawnie śledzą i czyszczą odwołania COM.

Po drugie, jeśli chcesz mieć pewność, że odwołania COM do poza procesem obiektu COM zostaną wyczyszczone po zakończeniu procesu (tak, że proces programu Excel zostanie zamknięty), musisz upewnić się, że działa Garbage Collector . Robisz to poprawnie, dzwoniąc pod numer GC.Collect() i GC.WaitForPendingFinalizers(). Podwójne wywoływanie jest bezpieczne, koniec zapewnia, że ​​cykle są zdecydowanie czyszczone.

Po trzecie, podczas działania pod debuggerem, lokalne odwołania będą sztucznie utrzymywane przy życiu aż do zakończenia metody (tak, że sprawdza się zmienna lokalna). Tak więc wywołania GC.Collect() nie są skuteczne w czyszczeniu obiektów takich jak rng.Cells z tej samej metody. Powinieneś podzielić kod wykonując interop COM od oczyszczania GC na osobne metody.

Ogólny wzór będzie:

Sub WrapperThatCleansUp() 

    ' NOTE: Don't call Excel objects in here... 
    '  Debugger would keep alive until end, preventing GC cleanup 

    ' Call a separate function that talks to Excel 
    DoTheWork() 

    ' Now Let the GC clean up (twice, to clean up cycles too) 
    GC.Collect()  
    GC.WaitForPendingFinalizers() 
    GC.Collect()  
    GC.WaitForPendingFinalizers() 

End Sub 

Sub DoTheWork() 
    Dim app As New Microsoft.Office.Interop.Excel.Application 
    Dim book As Microsoft.Office.Interop.Excel.Workbook = app.Workbooks.Add() 
    Dim worksheet As Microsoft.Office.Interop.Excel.Worksheet = book.Worksheets("Sheet1") 
    app.Visible = True 
    For i As Integer = 1 To 10 
     worksheet.Cells.Range("A" & i).Value = "Hello" 
    Next 
    book.Save() 
    book.Close() 
    app.Quit() 

    ' NOTE: No calls the Marshal.ReleaseComObject() are ever needed 
End Sub 

Istnieje wiele fałszywych informacji i zamieszanie na temat tego problemu, w tym wiele stanowisk na MSDN i na StackOverflow.

Co w końcu przekonało mnie do bliższego przyjrzenia się i znalezienia właściwej porady, to post https://blogs.msdn.microsoft.com/visualstudio/2010/03/01/marshal-releasecomobject-considered-dangerous/ wraz z odnalezieniem problemu z referencjami utrzymywanymi przy życiu w ramach debuggera na temat niektórych odpowiedzi StackOverflow.