Mit managed C++ gekapselte MFC- DLL - kann mir jemand helfen?

[P.A.]

Hallo Experten,

ich habe folgendes Problem:
Ich habe eine MFC- Erweiterungs-DLL. Um die zentrale Klasse habe ich eine verwaltete Wrapper- KLasse gebaut und kann damit die DLL sowohl in einer .NET- Applikation verwenden, als auch in meiner früheren MFC- Applikation verwenden.
Das funktioniert auch wirklich gut, und ich kann es debuggen. Schon weit drinnen im unverwalteten MFC- Code, kommt die Funktion an die Stelle, an der ein bereits mit new erstellter Dialog mit ::Create() kreiert werden soll...

// ParameterDialog schon mal kreieren, aber nicht anzeigen 
    if (m_pMVParameterDlg->GetSafeHwnd()==0)//NEIN- > dann Dialog kreieren 
    { 
        // Es werden Initialisierungen für den Dialog vorgenommen. 
        // Z.B. erhält er einen Zeiger auf DIESE KLasse. 
        m_pMVParameterDlg->DialogInitialisieren(this, m_pParamSet); 
        m_pMVParameterDlg->Create(IDD_MVPARAM_SET); 
        m_pMVParameterDlg->AktualisiereDialogCtrls(); 

        HideMVParamDefDlg(); 
    }

In ::Create steigt meine DLL dann aus, wenn ich Sie in der .NET- Applikation lade. Rufe ich die selbe DLL mit meiner MFC- Applikation auf, funktioniert das ::Create() wie immer.
Beim Parallelen Debuggen beider Varianten in die Tiefe der MFC (CDialog::Create) stelle ich fest, dass der Abflug bei
hinst = AfxGetRessourceHandle();
passiert, ohne, dass vorher für mich sichtbar Variablen unterschiedlich waren.

Ich kann mir das Problem nur so erklären, dass in der erfolgreichen Konstellation die MFC- Applikation Teile der MFC schon initialisiert hat, die dann auch der MFC- DLL zu Verfügung stehen. Wohingegen die .NET Applikation natürlich nichts vom MFC initialisiert und in jedem Fall die MFC- DLL alle Initialisierungen machen müsste.

Hat hier jemand einen zielführenden Rat für mich.
Vielen Dank im Voraus!

PS: Sorry, das Problem liegt auf der Grenze zwischen dem MFC und diesem Forum, deshlab habe ich den Beitrag in beiden gepostet. Ich hoffe, das ist OK?