Re: MemoryLeak using CWinFormsControl ?
I recall there is a problem with MFC's leaking of OccDialogInfo. Another
leak is in the CLR RCW objects created from COleControlSite's
IOleClientSite, IPropertyNotifySink and IEventSink implementations. Since
the control site is leaked, the control is also leaked.
There are plenty of discussions about whether or not release a COM interface
from RCW, and I run into crash problems when releasing RCW aggressively and
RCW is used after being released, but because not releasing these RCW after
the control site is destoryed would also cause crash when these objects are
finalized by GC so you need to choose the side that is less likely to crash
your program.
You can manually release a RCW for a given COM object by using
Marshal::GetObjectForIUnknown and Marshal::FinalReleaseComObject.This hack
needs to be performed after all MFC's call to the RCWs otherwise the program
will crash, so this requires studying MFC's source. Future versions of MFC
may introduce new RCW objects that needs o be released.
"Fr?d?ric Queudret [MVP]" <fredeq(supprimerceci)@mpoware.com> wrote in
message news:F1CC2191-07EF-4029-89AF-7BA22AFF2F29@microsoft.com...
Hi,
We are rewriting an old MFC/C++ App to .NET with C++/CLI interactions.
We are using CWinFormsControl (in our own classes or through
CWinFormsDialog) to host .NET UserControl that interoperate with the
native C++ code thru C++/CLI as documented on MSDN.
It seems that the .NET UserControls are not properly garbage collected
even after the C++ host has been correctly released and GC.Collect has
been called.
Did anyone experience this issue?
Is there any help or documentation on best practices on this subject?
Is there a way to force the .NET UserControl to be garbage collected?
We could provide sample code if needed (we have already done lots of tests
on Finalizer, explicit object destruction... but it seems that we're
missing something).
Thanks in advance for any help,
Fr?d?ric Queudret
http://www.mpoware.com/