Mixed mode ActiveX DLL

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi ,

I am trying to host .Net UserControls in a MFC Application. The MFC
Application is an ActiveX DLL. I inserted required managed code inside the
MFC application, making it a mixed mode DLL.
I am following the KB article for mixed mode DLL's
http://support.microsoft.com/?id=814472
I linked the DLL with /noentry option. Also I added and exported the
DllEnsureInit and DllForceTerm methods in my DLL which call
__crt_dll_initialize() and __crt_dll_terminate() respectively. So far so good.

Now in the consumer application, this ActiveX control is created dynamically
by the COleControlSite::CreateControl method. I understand that I would need
to invoke my init/term DLL functions manually after loading the the mixed
mode DLL.
How do I go about invoking these functions here ? The KB article
demonstrates use of GetModuleHandle and GetProcAddress which I believe may
not be usefule

Is this feasible ? Kindly advise.
Any inputs would be highly appreciated.
Thanks in advance,
Niranjan
 
The intention of the delayed CRT initialization is to avoid a deadlock,
which can happen if managed code is executed during DLLMain. After DLLMain
is called, your client will likely call DllGetClassObject to instantiate the
COM object. Unless some other code is called before DllGetClassObject, I
would initialize the CRT in your DllGetClassObject implementation.

Marcus
 
Hi Marcus,
Thanks for your reply.

I tried to investigate the current scenario without the CRT initialization
code in place. The client is calling the DllGetClassObject in library file
oleexp.cpp. I do not have my implementation of DllGetClassObject. If I try
to implement my DllGetClassObject in the DLL code, the linker gives error
saying DllGetClassObject is already linked from oleexp.cpp.

What would I need to do to provide and use my implementation of
DllGetClassObject ?

The call to DllGetClassObject is currently failing with
CLASS_E_CLASSNOTAVAILABLE (ClassFactory cannot supply
requested class ), which I would assume is because of lack of CRT
initialization.

Thanks,
Niranjan
 
I my answer, I assumed that you used ATL instead of MFC. In this case, it
would have been easy to overwrite DllGetClassObject.With MFC, the story is
more difficult. I currently don't have VS2003 installed on my machine.
Therefore, I can't easily try it before I suggest something. But you may try
the following:

Modify the .def file so that

EXPORTS
DllCanUnloadNow PRIVATE
DllGetClassObject = MyDllGetClassObject PRIVATE
DllRegisterServer PRIVATE
DllUnregisterServer PRIVATE

Implement MyDllGetClassObject so that you initialize the CRT if this has not
happened before. Once you ensured that the CRT is initialized, call
DllGetClassObject.

Please let us know if this works

Marcus
 
Hi Marcus,
Actually I did it in a different way and it works. Though it has taken me by
a bit of surprise. Heres the story - If I provide implementation of only
DllGetClassObject
the linker complains of multiply defined symbols. Same is the case if I just
implement DllCanUnloadNow. However if I implement both, the linker is happy
and moreover my implementations get used. I implemented both
DllGetClassObject and DllCanUnloadNow and put the CRT initilization in
DllGetClassObject. It worked.
What do you think have made this happen ? (is it an intelligent compiler /
linker ?)

Thanks,
Niranjan
 
Marcus,
I have tried it your way too and it works as well. However I have still not
been able to find how does the linker permits multiply defined symbols in my
case, as I have mentioned in the previous post.
Thanks.
 
Back
Top