Estou finalizando uma DLL de extensão MFC (MFCXDLL_2) para disponibilizar sua funcionalidade para programadores de C

O wrapper é uma “DLL comum usando DLL MFC compartilhada” com “Suporte ao Common Language Runtime (/ clr)”. (Modo misto)

As classes em MFCXDLL_2 que estarão disponíveis estão decoradas em MFCXDLL_

O cenário que estou enfrentando é o caso em que MFCXDLL_2 é usado em um controle de usuário C # .NET em execução em um aplicativo nativ

Outra DLL de extensão MFC - MFCXDLL_1 - dentro do aplicativo nativo também usa o MFCXDLL_2 e isso causa problema

Quando inicio o aplicativo nativo, ele carrega implicitamente o MFCXDLL_

Quando carrego o controle de usuário .NET, o mesmo MFCXDLL_2 é carregado novamente explicitamente, de acordo com os conselhos emhttp: //msdn.microsoft.com/en-us/library/ksa99t88.asp, “Usando DLLs de banco de dados, OLE e extensão de soquetes em DLLs regulares”

O código nativo e o controle de usuário .NET instanciam o mesmo tipo de classe e chamam o mesmo método no MFCXDLL_

O método desserializa os dados (recebidos pela memória compartilhada) e retorna os dados desserializados para o chamador. Isso funciona muito bem a partir do código nativo até carregar o controle de usuário .NET.

Depois de carregar o controle de usuário .NET, a desserialização para de funcionar a partir do código nativo, mas funciona muito bem quando chamada do controle de usuário .NE

Anexei o WinDbg à versão de depuração do aplicativo nativo e execute o meu cenário. WinDbg encontrado da seguinte forma durante a desserialização:

“Aviso: Não é possível carregar do arquivo. Classe não definida. CA exceção de arquivo: badClass. ”

Eu acho que existem alguns problemas de recursos aqui, então eu executo a versão do aplicativo nativo que carrega a versão do MFCXDLL_2. Em seguida, carrego a versão de depuração do controle de usuário do .NET - que carrega novamente a versão de depuração do MFCXDLL_2- no aplicativo nativ

Então tudo funciona muito bem. Uma versão do MFCXDLL_2 carregada pelo código nativo e uma versão de depuração do MFCXDLL_2 carregada pelo controle de usuário do .NET - tudo em execução no aplicativo nativo.

Então, o que está acontecendo? Não é possível acessar o mesmo MFCXDLL de p. uma extensão DLL e uma DLL comum ao mesmo tempo no mesmo aplicativo?
A cadeia de recursos é destruída de alguma forma? Quais são as soluções possíveis

Aqui está um código que mostra como a DLL MFCXDLL_2 é carregada
Quando o aplicativo nativo inicia, o MFCXDLL_2 DLLMain é chamado:

static AFX_EXTENSION_MODULE MFCXDLL_2 = { NULL, NULL };
static CDynLinkLibrary* gpDynLinkLibrary = NULL;

extern "C" int APIENTRY
DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID )
{
  if (dwReason == DLL_PROCESS_ATTACH)
  {
        // Extension DLL one-time initialization
        AfxInitExtensionModule(MFCXDLL_2, hInstance);

        // Insert this DLL into the resource chain
        gpDynLinkLibrary = new CDynLinkLibrary(MFCXDLL_2);
  }
  else if (dwReason == DLL_PROCESS_DETACH)
  {
        if (gpDynLinkLibrary)
        {
              delete gpDynLinkLibrary;
              gpDynLinkLibrary = NULL;
        }
        // Terminate the library before destructors are called
        AfxTermExtensionModule(MFCXDLL_2);
  }
  return 1;   // ok
}

Quando o controle de usuário .NET é carregado, a DLL MFCXDLL_2 é carregada novamente:

//==============================================================
// Exported DLL initialization to run in context of Regular DLL.
// Must be called in InitInstance
// BOOL CYourRegularDLLApp::InitInstance()
//==============================================================
extern "C" _declspec(dllexport) CDynLinkLibrary* WINAPI InitMFCXDLL_2FromRegularDLL()
{
    if (gpDynLinkLibrary)
    {
        delete gpDynLinkLibrary;
        gpDynLinkLibrary = NULL;
     }
     // Create a new CDynLinkLibrary for this Regular DLL
     return new CDynLinkLibrary(MFCXDLL_2);
}

O código de desserialização dentro de MFCXDLL_2

    CMyClass* pMyclass = NULL; //CObject derived serializeable class
    BYTE *pBuf      = pGlobalCom->GetBuffer(); //Buffer with serialized CMyClass
    int nBufSize    = pGlobalCom->GetSize();   //Size of buffer

    CMemFile mf;
    mf.Attach(pBuf,nBufSize);

    CArchive ar(&mf, CArchive::load); //“Warning: Cannot load CMyClass from archive.  Class not defined.CArchive exception: badClass.”

    ar >> pMyclass; //CArchive exception thrown
    ar.Close();
    mf.Detach();

A imagem mostra a relação entre as dlls.