.NET Component called from COM Component not released

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

wschaub - 30 May 2005 11:15 GMT

We have a test environment in which we instantiate a COM/ATL/C++ component
from a Managed/Console/.NET/C# application. The COM component in turn
instantiates and calls a .NET/C#/Class Library component using Interop as
below:

#import "demologger.tlb" raw_interfaces_only named_guids no_namespace
// log using .NET Interop
CComPtr<IDemoLogger> pILogger;
bstr_t bstrMessage = "Hello from COM to .NET";

hResult = pILogger.CoCreateInstance ( CLSID_DemoLogger,
NULL,
CLSCTX_SERVER );
if ( 0 == hResult ) pILogger->LogToFile ( bstrMessage );
else return S_FALSE;

// We are done
pILogger = NULL;

Even if this logic and the CComPtr go out of scope and the reference count
is decremented, neither the destructor or the Dispose methods of the .NET
component are called. How can we ensure/enforce disposal or components used
via Interop?

Flow is:

Console/.NET ---> COM/ATL component ---> .NET Component

Reply to this Message

Fakher Halim - 31 May 2005 17:35 GMT

Please add "GC.Collect();" after your are done, e.g.

// We are done
pILogger = NULL;
GC.Collect();

Fakher Halim
Software Architect
TPG

> We have a test environment in which we instantiate a COM/ATL/C++ component
> from a Managed/Console/.NET/C# application. The COM component in turn
[quoted text clipped - 23 lines]
>
> Console/.NET ---> COM/ATL component ---> .NET Component

Reply to this Message

wschaub - 01 Jun 2005 07:40 GMT

How can we add GC.Collect() to the COM/ATL Component, which is making the
call from unmanaged to managed code?

> Please add "GC.Collect();" after your are done, e.g.
>
[quoted text clipped - 34 lines]
> >
> > Console/.NET ---> COM/ATL component ---> .NET Component

Reply to this Message

Fakher Halim - 01 Jun 2005 16:49 GMT

wschaub
Sure COM/ATL Components dont have garbage collection issues. It is the
managed code where the objects are not deleted unless we force garbage
collection deterministically.
All we can try doing is create a public (try static) function in .NET
managed code that could be called from the unmanaged code. Typically we may
want to implement
IDisposable interface and create void Dispose() function that makes
references to unmanaged resource to NULL before calling GC.Collect();
Sure it is a tricky situation, but we need to trigger the garbage collector
in managed objects before all the distructors/finalizers get called via
domino effect.

Fakher Halim
Software Architect
TPG

> How can we add GC.Collect() to the COM/ATL Component, which is making the
> call from unmanaged to managed code?
[quoted text clipped - 21 lines]
> > > hResult = pILogger.CoCreateInstance ( CLSID_DemoLogger,
> > > NULL,

CLSCTX_SERVER );

> > > if ( 0 == hResult ) pILogger->LogToFile ( bstrMessage );
> > > else return S_FALSE;
[quoted text clipped - 11 lines]
> > >
> > > Console/.NET ---> COM/ATL component ---> .NET Component

Reply to this Message

Phil Wilson - 02 Jun 2005 19:13 GMT

A couple or three ideas in no particular order.

piLogger=NULL;
I haven't stepped through that or looked at the code - does it call Release
on the wrapped interface pointer?

In the Console.NET client - see if Marshal.ReleaseComObject helps release
from the bottom up.

In the ATL component, if you want to free idle DLLs, see if
CoFreeUnusedLibraries helps.

You won't get Dispose called - who's going to call it? I don't believe that
COM client wrappers look for IDisposable, so if it's important expose it as
a method.

Signature

Phil Wilson [MVP Windows Installer]
----

> We have a test environment in which we instantiate a COM/ATL/C++ component
> from a Managed/Console/.NET/C# application. The COM component in turn
[quoted text clipped - 24 lines]
>
> Console/.NET ---> COM/ATL component ---> .NET Component

Reply to this Message

.NET Component called from COM Component not released

Free Magazines