Hi Willy,
thanks for your answer.
This is mainly what we found out so far:
If a cpp which is compiled with /clr includes afxdisp.h, the MFC include
files tell the linker to also link with postdllmain.obj
If the postdllmain.obj is linked, some static variable inside MFC (something
like usemanagedinitialization) is set to 1.
When the dll is loaded the dllmain of MFC constructs all the unamanged
globals, and if the variable is 1 it skips InitInstance totally
The initinstance is later executed using "internaldllmain" call from .cctor
of managed global object which is inside the postdllmain.obj
The funny effects are mainly based on our construction code, which is
usually executed in InitInstance.
But I'm also not sure if MFC behaves correctly if we call AFX_MANAGE_STATE()
and InitInstance is not yet called.
Frank
[quoted text, click to view] "Willy Denoyette [MVP]" <willy.denoyette@telenet.be> wrote in message
news:eJpTQMYBGHA.984@tk2msftngp13.phx.gbl...
>
> "Frank Samuel" <FSamuel_nospam@misag_remove_spam.com> wrote in message
> news:e11BKiVBGHA.1028@TK2MSFTNGP11.phx.gbl...
>> Hi,
>> we found a problem with the way managed MFC dlls work:
>>
>> CWinApp::InitInstance is sometimes just called when the managed
>> initialization is done (cctor).
>> This is the case if one of the files using /clr is including afxdisp.h
>>
>> The problem is that the managed initialization is just executed if a
>> managed object is required.
>> If an unmanaged function is called (like DllRegisterServer), CWinApp is
>> not yet initialized which causes funny problems in our application.
>>
>> Does anybody have a good idea how to solve this?
>>
>> Thanks,
>> Frank
>>
>
> Frank,
> What exactly do you mean with "managed initialization is done"? And what
> exactly are "Funny problems"?
> You CWinApp is a native class so it's instance is not handled by the CLR,
> but by MFC. As your MFC app. is a mixed application, that is the MFC
> libary linked in is still unmanaged code, your classes are still native,
> all there is done by the CLR is JITting your applications code from IL to
> native X86 code.
>
> Willy.
> PS. As this relates to VC++ I would suggest you post to the more
> appropriate NG at microsoft.public.dotnet.languages.vc.
>
>
>
>
