Imagine the following situation.

I have an EXE COM server A.exe that in turn uses some in-proc servers B.dll.
Some of the coclasses defined in A.exe may pass to the ultimate client
references to objects defined in B.dll.

E.g. they may have methods doing something like this

HRESULT CClassDefinedInA::GetBObject( /*[out]*/ IInterfaceDefinedInB* pObject )
{
    ...
    CreateInstance( ... CLSID_CoClassDefinedInB ... (void**)&pObject );
    return S_OK;

It may eventually happen that the ultimate client releases all references to
objects defined in A.exe, but still holds references to objects defined in B.dll.
Note, that client executable does not load B.dll itself. It references objects
that live inside B.dll in the address space of A.exe.

A.exe is written using ATL.

Obviously, B.dll knows nothing about A.exe's _Module object and its lock mechanism.
If all objects from A.exe are released, reference count in the _Module will drop to
zero, and the server will unload. This will kill all the objects from B.dll that client still needs.

How can I make A.exe to take objects from B.dll into account and unload only
if all objects from A.exe **and** all objects from B.dll are released?

Ivan

You can wrap every pointer you serve from the DLL with your object,
especially if DLL-implemented objects support aggregation. This wrapper
object would then correctly maintain server's reference count.

Other than that, you can call DllCanUnloadNow in CExeModule::Unlock and
not exit if DLL is still serving something. Then you would have to call
DllCanUnloadNow periodically, to determine when it is finally ready.
--
With best wishes,
    Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken

B.dll that client still needs.

Thank you.
I thought about both of these possibilities, bet rejected them as too complicated.
Besides, both of them have serious maintenance drawbacks.

First solution requires to write a new (albeit simple) coclass for every coclass I
define in the DLL and want to pass to the client.

Second solution forces me to keep a list of DLLs I use and probably add special
thread of execution to periodically check status of B.DLL.

If I assume that source code of B.DLL is under my control and it is written in ATL,
can I do better?

Ivan

You could make all objects in your DLLs aggregatable. The EXE can then
use one simple blind-aggregating object as an outer object each time it
serves an object from a DLL, just to maintain a reference count. This
breaks, however, if DLL objects' methods create new objects in their
turn. Those won't be wrapped, naturally.

You can make each DLL object implement one extra interface, with the
only method that accepts IUnknown pointer. The object promises to keep
this pointer AddRef'ed during its lifetime, and to pass it along in the
same way to each object it itself creates. The EXE then can have a
simple object implementing nothing beyond IUnknown, and pass its pointer
to every DLL object it creates.

There does not seem to be an easy and reliable method to do what you
want.
--
With best wishes,
    Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken