Question

My managed application consumes legacy functionality exposed by a native COM dll via a managed wrapper. I cannot change the COM dll nor its managed wrapper.

• The managed wrapper is in essence automatically generated by a script, given the COM type declarations as input.
• The COM layer will internally access network, file system, graphics and other unmanaged resources.
• Most managed types in the wrapper are created using factory-like methods.
• Most managed types in the wrapper has no way of manually trigger clean-up or resource-release.
• No managed type in the wrapper implements IDisposable.
• No managed type in the wrapper explicitly implements a finalizer.

I feel that I’m missing a lot in my application layer from this API that I’d like to see in order to ensure that unmanaged resources are properly being released.

The question is if I’m right in my understanding of this:

Given that the application layer no longer references an object from the managed wrapper, there’s no way that underlying native objects used by that managed object can ever be released until an exposed cleanup method explicitly does so.

Am I correct in that?

Answer 1

No that is not quite correct. When the garbage collector collects managed types that are referencing the COM types those references will be dereferenced using the COM Release call. At ths point the unmanaged resources will be released assuming nothing else is reference the COM object instance.

However unless you are calling GC.Collect() (a fairly draconian thing to do) then it is possible for those unmanaged resource are held onto for far, far longer than necessary.