COM Interoperability Life time Management

[shethashish_a]

Hi all gurus,
How .NET manages the life time of a COM object that is called from a
.NET assembly using COM interoperability? My doubt is, COM uses
reference counting for life time management while .NET objects are
garbage collected. so when a COM object will not have any references to
it in .NET assembly it should be released from the memory but the actual
.NET proxy may not be released untill the garbage collector runs. so
when actually the COM object will be released from the memory?

thanks and regards,

[poochi]

Ashish, the following is an excerpt from MSDN magazine (2001). I hope it is not changed over the period of time (with the latest .Net versions). I hope it will clear your doubt. I assume you already know about RCW.

When you run the sample COM client program, you'll notice (from dialog boxes that I placed in the code) that the object is created when you click the button, and then immediately destroyed. When you run the sample .NET client program, you'll find that the object is created when you click the Get Time button, but that the object isn't destroyed immediately. You would think it should be, as the wrapper object goes out of scope, but it isn't, not even if you explicitly set the object reference to nothing. This is the .NET way of lazy resource recovery, described in Jeffrey Richter's articles on .NET garbage collection in the November and December 2000 issues of MSDN Magazine. The RCW has gone out of scope and is no longer accessible to your program, but it doesn't actually release the COM object that it wraps until the RCW is garbage collected and destroyed, which may happen at any later time. This can be a problem, as most COM objects were not written with this lifecycle in mind and thus might retain expensive resources that should be released as soon as the client is finished.
You can solve this problem in one of two ways. The first, obviously, is by forcing an immediate garbage collection via the System.GC.Collect function. Calling this function will collect and reclaim all system resources that are no longer in use, including all the RCWs not currently in scope. The drawback to this approach is that the overhead of a full garbage collection can be high, and you may not want to pay that price immediately just to shred one object, just as Julia Child often wipes off her favorite paring knife without cleaning up her entire kitchen. If you would like to blow away one particular COM object without affecting the others, you can do so via the System.Runtime.InteropServices.Marshal.ReleaseComObject function.

Poochi...

[shethashish_a]

Thank's poochi,
That's what I wanted to know!!!
can you send me the link of the MSDN article?


now tell me what happens when an unmanaged code or COM components calls a .NET component? as again COM components are reference counted and .NET component are garbage collected, how can a CCW wrapper around a .NET component set its reference count to 0 until the actual .NET component is not garbage collected?

thanks again!!!

[poochi]

I am posting the entire (tiny) article I found in msdn (Apr. 2003). It answers some of the basic questions. I hope it will be very helpful to others also. (.Net framework developer's guide. Title - "COM Callable Wrapper")

When a COM client calls a .NET object, the common language runtime creates the managed object and a COM callable wrapper (CCW) for the object. Unable to reference a .NET object directly, COM clients use the CCW as a proxy for the managed object.

The runtime creates exactly one CCW for a managed object, regardless of the number of COM clients requesting its services. As the following illustration shows, multiple COM clients can hold a reference to the CCW that exposes the INew interface. The CCW, in turn, holds a single reference to the managed object that implements the interface and is garbage collected. Both COM and .NET clients can make requests on the same managed object simultaneously.

Accessing .NET objects through COM callable wrapper



COM callable wrappers are invisible to other classes running within the .NET Framework. Their primary purpose is to marshal calls between managed and unmanaged code; however, CCWs also manage the object identity and object lifetime of the managed objects they wrap.

Object Identity

The runtime allocates memory for the .NET object from its garbage-collected heap, which enables the runtime to move the object around in memory as necessary. In contrast, the runtime allocates memory for the CCW from a noncollected heap, making it possible for COM clients to reference the wrapper directly.

Object Lifetime

Unlike the .NET client it wraps, the CCW is reference-counted in traditional COM fashion. When the reference count on the CCW reaches zero, the wrapper releases its reference on the managed object. A managed object with no remaining references is collected during the next garbage-collection cycle.

I found that MSDN Magazine(August 2001) article in MSDN library(Apr. 2003). I have given the title of the article below. Give it a try in the online MSDN library site.

".NET Interop: Get Ready for Microsoft .NET by Using Wrappers to Interact with COM-based Applications"

[shethashish_a]

thanks poochi,
this is really very useful.
Now another issue is there,
we can have a private .net assembly or a shared .net assembly. if we are going to interop these assembly with COM we have to register it using regasm.exe tool so every COM client can access these assemblies.
now if we use private assemblies and register it with COM, can every COM client access our assembly, because ideally we need to install and register a COM component only once so that it can be accessed to any number of client application.
suppose App1 is the client application to our private .NET assembly MyAssembly1. MyAssemby1 is registered in the registery using regasm.exe. Now can another application App2 see the type information of MyAssembly1? and can it access the methods of MyAssembly1?

regards,