Tadwick

I am writing an Outlook add-in using VS2005 (VSTO SE). At startup I load a windows form that contains a .Net 2.0 ActiveX webbrowser control. When the forms loads the control navigates to a URL which uses the Adobe SVG Viewer ActiveX control inside the page. At this point I get a loader lock.

This does not happen if I use the Adobe ActiveX control in a plain windows app or if I access other ActiveX controls from the Outlook add-in.

I know that Outlook add-ins require a mix of managed and unmanaged code. Is there any way I can diagnose the issue more thoroughly or, even better, resolve it so that the conflict doesn't occur (aside from turning off the Loader Lock MDA - which doesn't help because the add-in and Outlook hang anyway).

Thanks, Tad



Re: Common Language Runtime Loader Lock Issue

utkarsh mandot

DLL that contains consumers that use managed code and dll exports or
managed entry points

The minitialize and mterminate functions are straight forward and make
sense. The problem is with the code

BOOL WINAPI DllMain(HINSTANCE hModule, DWORD dwReason, LPVOID
lpvReserved) {
Console::WriteLine(S"DllMain is called...");
return TRUE;
} /* DllMain */


Now, this seems to me that this code violates the rule that no managed
code should be run under loader lock.

I have a c# main program.

static void Main(string[] args)
{
ManagedWrapperr.minitialize();
,,,,,
ManagedWrapperr.mterminate();
}

And to no surprise I see the following output
DllMain is called...
__crt_dll_initialize is called...

(I added the line Console::WriteLine(S"__crt_dll_initialize is
called...");
in minitialize after the call to __crt_dll_initialize.

I would assume that putting a managed dll in the references (or in the
#using list) would be the same as making it statically linked in
non-managed environment. If that is the case then how does this code
actually do us any good (The implication being that the load caused
by the referencing managed code as in turn called to OS to do the DLL
load which as already called DLLMAIN which should have run the
non-managed dll initialize (__crt_dll_initialize).

Prior to putting the work around code into my dll, I did not have a
user defined DLLMAIN therefore my DLLMAIN should (I would expect) have
been unmanaged only, so why do I even get the loader lock problem to
start with