2011-08-02 3 views
2

J'utilise Visual Studio 2010 .Net 4.0 ciblageC++: Emballage dll non géré à l'aide à l'exportation dll

Je travaille avec une dll C++ non géré à l'aide d'une enveloppe C++ géré. J'utilise _declspec (dllexport) pour exporter le fichier .dll non géré ci-dessous est le fichier d'en-tête pour la dll non gérée:

class DllExport KeyManager 
{ 
public: 
KeyManager(const char *pszKeyFileName, int thisProduct); 
~KeyManager(); 
... 

Je puis faire un appel à la dll non géré à partir du wrapper managé ici:

#include "stdafx.h" 
#include "KeyModCLR.h" 
#using <mscorlib.dll> 
#include <msclr/marshal.h> 

using namespace System; 
using namespace System::Runtime::InteropServices; 
using namespace msclr::interop; 


MCKeyManager::MCKeyManager(String ^fileName, int thisProduct) 
{ 
    pszFileName = (char*)Marshal::StringToHGlobalAnsi(fileName).ToPointer(); 
    m_pC = new KeyManager(pszFileName, thisProduct); 
} 

tout cela fonctionne très bien lorsque le projet cible Win32, mais quand je change la plate-forme cible à 64 bits comme décrit here je reçois l'erreur suivante:

Error 17 error LNK2019: unresolved external symbol "public: __cdecl  

KeyManager::KeyManager (char const *,int)" ([email protected]@[email protected]@Z) referenced in 
    function "public: __clrcall MCKeyManager::MCKeyManager(class System::String ^,int)" (?? [email protected]@[email protected][email protected]@@[email protected])  

Je suis pas très familier avec le C++ car je n'ai pas écrit ce code donc je ne sais pas s'il me manque quelque chose d'évident. J'ai lu que la décoration des fonctions importées est différente pour 64 bits et 32 ​​bits mais je ne suis pas sûr de la façon dont cela m'affecte nécessairement.

J'ai été à la recherche d'une réponse toute la journée et je suis venu à court pour toute suggestion ou conseil serait grandement appréciée.

Merci à l'avance

Répondre

2

Ce type d'erreur est probablement attribuable à la configuration du Gestionnaire de configuration. Lorsque vous configurez la configuration x64, le gestionnaire de configuration définit souvent les fichiers .dll dépendants à compiler sous Win32 au lieu de x64. Ouvrez Configuration Manager pour la solution, vérifiez les paramètres de chaque projet. Vérifiez qu'ils vont créer une configuration x64 et qu'ils sont activés pour la construction.

Une autre vérification utile est la convention d'appel. Par exemple, si un projet utilise _cdecl et qu'un autre utilise _stdcall, les appels entre les projets échoueront. Le message d'erreur affichera la convention d'appel utilisée par le projet appelant. Vous pouvez utiliser DUMPBIN/EXPORTS sur le fichier .dll ou .lib cible pour connaître la convention d'appel en cours d'exportation. (DUMPBIN est dans le dossier VC/bin).

Questions connexes