Estou criando uma DLL C ++ / CLI que será carregada em um aplicativo c ++ herdado. O aplicativo legado faz isso com uma chamada tradicional para LoadLibrary. O aplicativo e a DLL C ++ / CLI são compilados no modo de 64 bit

Quando a chamada LoadLibrary acontece, ela falha com o erro 193. Isso geralmente significa que algum componente não de 64 bits está tentando carregar. Quando olho para a saída de carregamento da dll no visual studio 2010, vejo que a falha está ocorrendo quando o mscoree.dll está sendo carregado (para ser exato, vejo minha dll carregada, depois mscoree carregada, depois mscoree descarregada e a minha dll descarregada , o erro retornou). Especificamente, C: \ Windows \ System32 \ mscoree.dll está sendo carregado. Quando examino este mscoree.dll, percebo que ele está direcionado para I386.

Como posso garantir que meu aplicativo seja vinculado ao mscoree.dll correto? Entendo que isso poderia ser feito com um manifesto, mas não consigo encontrar nenhuma informação boa sobre como configurá-lo. A solução ideal permitiria a compilação no modo de 32 bits ou 64 bits e atingiria o mscoree.dll corret

Como uma observação lateral, encontrei um mscoree.dll em uma pasta lado a lado que verifiquei no modo de 64 bits e copiei-o no diretório de aplicativos com a esperança de que ele pegasse esse primeiro. Isso não funcionou e a versão C: \ Windows \ System32 ainda estava carregad

Obrigado

Max

Saída do CorFlags.exe na dll C ++ / CLI

Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  4.0.30319.1
Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v4.0.30319
CLR Header: 2.5
PE        : PE32+
CorFlags  : 16
ILONLY    : 0
32BIT     : 0
Signed    : 0

Saída do pedump.exe em C: \ System32 \ mscoree.dll

PS C:\Windows\System32> pedump.exe .\mscoree.dll
Dump of file .\MSCOREE.DLL

File Header
  Machine:                      014C (I386)
  Number of Sections:           0004
  TimeDateStamp:                4B90752B -> Thu Mar 04 22:06:19 2010
  PointerToSymbolTable:         00000000
  NumberOfSymbols:              00000000
  SizeOfOptionalHeader:         00E0
  Characteristics:              2102
    EXECUTABLE_IMAGE
    32BIT_MACHINE
    DLL
...

(o pedump continua daqui para descrever as importações e exportações, mas isso não é importante aqui)

Informações de carregamento estendidas

Esta é a saída completa do carregamento com falh

Nota: A DLL C ++ / CLI é chamada DsfClr.dll
a saída foi obtida executando gflags.exe -i [nome]] + sls e examinando os resultados em um depurador

http: //pastebin.com/FyumUiM

ATUALIZAR

Usando uma dica postada em um comentário abaixo de Reuben, eu pude determinar que o mscoree.dll está realmente mirando no AMD64, mas o pedump está fornecendo informações inválidas porque está sendo executado no WOW64. Dito isto, ainda não consigo carregar esta biblioteca, se alguém tiver alguma sugestão, seria muito apreciada.
Mais uma coisa que tentei: criei um novo aplicativo C # e referenciei a DLL C ++ / CLI; em seguida, na função main (), instanciei uma classe na DLL C ++ / CLI. Isso causou uma exceção de violação de acesso antes da função main () ser chamada. Quando removo a instanciação, a função principal funciona bem. Meu palpite é que a instanciação está causando um atraso no carregamento do meu assembly C ++ / CLI, o que causa o mesmo erro de carregamento que eu estava vendo no assembly nativ