Typelib indirect pas bien importé de dll Debug

Question

Avec VC2005, j'ai 3 projets à construire:

• libA (contient une typelib, résultats dans libA.dll): IDL a une ligne library libA { ...
• libB (contient une bibliothèque de types important libA, les résultats dans libB.dll): IDL a une ligne importlib( "libA " );
• libC (importations libB): l'un des fichiers source contient #import <libB.dll>

le __missing_type__ est géré par le compilateur de la manière suivante (selon la documentation):

1. répertoires de recherche de% PATH%
2. répertoires de recherche de% LIB%
3. recherchez les " chemins d'inclusion supplémentaires " (Option du compilateur / I)

Lors de la compilation de libC, je peux voir que cl.exe est clairement capable de trouver le libA.dll sur le chemin de l'exécutable (à l'aide de Filemon.exe)

Erreur VC C4772: # import de la bibliothèque de types avec une autre dépendance

Cependant, l'espace de noms libA n'est toujours pas introuvable et toutes les références aux types libA sont remplacées par <=>

.

(edit) Pendant ce temps, j'ai découvert que le problème n'apparaissait que lors de l'utilisation des dll de débogage.

Quelqu'un a déjà vu ce problème? Et résolu?

Answer 1

Enfin trouvé!

Dans le projet Visual Studio, le fichier A.idl de LibA avait le paramètre Compatible MkTypeLib activé. Cela a annulé le comportement hérité du projet A. Pour aggraver les choses, il n’était activé que dans la configuration Debug.

La conséquence était que pour chaque

typedef [public] tagE enum { cE1, cE2 } eE;

Cela a abouti à ce que tagE ne soit pas défini dans la bibliothèque de types résultante. Quand LibB l'a fait c'est import( "A.dll" ), toutes les références à __missing_type__ ont été remplacées par <=> ...

Answer 2

Définissez-vous explicitement les dépendances du projet? En d'autres termes, avez-vous configuré la solution dans l'EDI pour que le projet C dépende du projet B et que le projet B dépende du projet A?

Answer 3

Utilisez-vous les types définis dans libA à partir de libC? Si c'est le cas, je pense que vous devez importer directement libA de libC afin qu'il connaisse les types de libA. COM ne référence pas automatiquement les bibliothèques de types qui sont elles-mêmes référencées par une autre bibliothèque de types.

Answer 4

Je n'ai pas de réponse pour vous, mais j'ai vécu cette expérience plusieurs fois et j'aimerais partager ce que j'ai fait.

Sur plusieurs projets indépendants, j'ai eu votre même scénario. J'ai essayé pendant près d'une semaine dans un cas de résoudre les dépendances, mais j'ai finalement dû réduire mes pertes pour rester dans les délais. J'ai fini par utiliser un #include sur le fichier .tlh (une importation sur la DLL les générera), puis en utilisant & "; Classique com &"; api appelle pour obtenir des pointeurs sur les structures dans les fichiers .tlh. Le code n'est pas aussi propre à utiliser que si vous pouviez utiliser les fichiers wrapper, mais cela fonctionne.

IUnknown *lpUnk;
hr = CoCreateInstance(clsID, NULL, CLSCTX_LOCAL_SERVER, IID_IUnknown, (void **)&lpUnk);
if (FAILED(hr)) throw SomeException;  

                                          //
_Application *app;                        //Address _Application  
hr = lpUnk->QueryInterface(__uuidof(_Application), (void **) &app);
lpUnk->Release();
if (FAILED(hr)) throw SomeException;  

                                          // Do stuff with the app object  
app->Release();                           // Then release

Vous pouvez en quelque sorte " dépolluer " utilisez le modèle d’encapsuleur CComPtr pour effectuer la libération de manière fiable à partir de son destructeur lorsqu’il sort de la portée:

CComPtr<IUnknown> lpUnk;
hr = CoCreateInstance(clsID, NULL, CLSCTX_LOCAL_SERVER, IID_IUnknown, (void **)lpUnk);
if (FAILED(hr)) throw SomeException;  
                                          //
CComPtr<_Application> app;                //Address _Application  
hr = lpUnk->QueryInterface(__uuidof(_Application), (void **) &app);
if (FAILED(hr)) throw SomeException;
                                         //
                                         // Do stuff with the app object

Notez que le pointeur _Application est un exemple d'utilisation de l'une des structures d'un fichier .tlh.