Typelib indiretto non importato bene dalla DLL di debug

Question

Usando VC2005, ho 3 progetti da costruire:

• libA (contiene un typelib, risulta in libA.dll): IDL ha una riga library libA { ...
• libB (contiene un typelib che importa libA, risulta in libB.dll): IDL ha una riga importlib( "libA " );
• libC (importa libB): uno dei file di origine contiene #import <libB.dll>

il __missing_type__ è gestito dal compilatore nel modo seguente (secondo la documentazione):

1. directory di ricerca di% PATH%
2. directory di ricerca di% LIB%
3. cerca il " percorsi di inclusione aggiuntivi " (Opzione del compilatore / I)

Durante la compilazione di libC, posso vedere che cl.exe è chiaramente in grado di trovare libA.dll sul percorso eseguibile (usando Filemon.exe)

Errore VC C4772: #importazione di typelib con un'altra dipendenza

Tuttavia, lo spazio dei nomi libA è ancora non trovato e tutti i riferimenti ai tipi di libA sono sostituiti da <=>

(modifica) Nel frattempo, ho scoperto che il problema appare solo quando si usano le DLL di debug.

Qualcuno ha visto questo problema prima? E risolto?

Answer 1

Finalmente trovato!

Nel progetto Visual Studio, il file A.idl in LibA aveva l'impostazione Compatibile MkTypeLib . Ciò ha annullato il comportamento ereditato dal progetto A. A peggiorare le cose, era attivo solo nella configurazione di debug.

La conseguenza è stata quella per ogni

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

Ciò ha comportato che tagE non è stato definito nel typelib risultante. Quando LibB lo ha fatto è import( "A.dll" ), tutti i riferimenti a __missing_type__ sono stati sostituiti con <=> ...

Answer 2

Stai impostando esplicitamente le dipendenze del progetto? In altre parole, hai impostato la soluzione nell'IDE in modo che il progetto C dipenda dal progetto B e il progetto B dipenda dal progetto A?

Answer 3

Stai usando tipi definiti in libA da libC? In tal caso, penso che sia necessario importare direttamente libA da libC in modo che sia a conoscenza dei tipi di libA. COM non fa automaticamente riferimento alle librerie dei tipi a cui essi stessi fanno riferimento da un'altra libreria dei tipi.

Answer 4

Non ho una risposta per te, ma ho avuto questa esperienza diverse volte e vorrei condividere ciò che ho fatto.

Su diversi progetti non correlati, ho avuto il tuo stesso scenario. Ho provato per quasi una settimana in un caso a risolvere le dipendenze, ma alla fine ho dovuto tagliare le mie perdite per rimanere nei tempi previsti. Ho finito per usare un #include sul file .tlh (eseguendo un'importazione sulla DLL li genererà), quindi usando & Quot; classic com & Quot; api chiama per ottenere puntatori alle strutture all'interno dei file .tlh. Il codice non è pulito con cui lavorare come se fosse possibile utilizzare i file wrapper, ma funziona.

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

Puoi in qualche modo " de-uglify " questo usando il template wrapper CComPtr per eseguire il rilascio in modo affidabile con il suo distruttore quando esce dall'ambito:

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

Si noti che il puntatore _Application è un esempio dell'uso di una delle strutture da un file .tlh.