none
Cleanup .NET COM component after "unexpected end" of unmanaged host application RRS feed

  • Question

  • Hi, I have an unmanaged host application (Microsoft Dynamics NAV, for who's interested) that creates a .NET COM object (C#, COM-visible, etc.). Now the host application comes in an error state, the created COM object is (automatically) cleared, but the app is still running, so no GC for my .NET object. There is no way I can prevent the error state or handle that error and instruct my .NET object to free it's resources and "shut down" awaiting GC.

    There is an ugly way to work around this problem: Create a VB6 COM wrapper that creates the .NET COM object and let NAV create the VB6 wrapper. When encountering error state, the VB6 wrapper's destructor fires and that will call a .NET object function which does cleaning up.

    My question is: Is there any better way for my .NET COM object to know it is no longer "needed" ?

    Thanks in advance,

    Remco
    Wednesday, December 10, 2008 8:39 PM

All replies

  • Are you sure the object isn't garbage collected eventually?

    If the host correctly releases a VB6 COM object, it should also correctly release the CCW that references your managed object.
    Mattias, C# MVP
    Thursday, December 11, 2008 9:52 AM
    Moderator
  • As long as the dying host thread is correctly calling the COM object's Release() method, the GC will eventually collect the .NET object.  Considering this was an unhandled error, that's not that likely.  Leaving an app running after an unhandled exception is asking for boatloads of trouble.
    Hans Passant.
    Thursday, December 11, 2008 1:00 PM
    Moderator
  • Mattias Sjögren said:

    Are you sure the object isn't garbage collected eventually?

    If the host correctly releases a VB6 COM object, it should also correctly release the CCW that references your managed object.


    Thanks for your reaction. Yes eventually it will be, but eventually is too long for the job. The CCW is probably correctly released, but the managed object is awaiting GC while keeping resources occupied. And that is just what I want to prevent.
    Thursday, December 11, 2008 3:16 PM
  • nobugz said:

    As long as the dying host thread is correctly calling the COM object's Release() method, the GC will eventually collect the .NET object.  Considering this was an unhandled error, that's not that likely.  Leaving an app running after an unhandled exception is asking for boatloads of trouble.


    Hans Passant.



    Thank you for your reaction. See my previous reaction for the GC story. The error is not entirely unhandled, it is unhandled by programmable code due to the restricted development environment MS NAV offers. The error is handled by the NAV environment (a service in this case) which will end the code that created the CCW and then starts the code again which creates a new instance of the CCW.

    That Release() method that is called, can I do something with that in the managed code?
    Thursday, December 11, 2008 3:24 PM