Indirekte Typelib nicht gut aus Debug-DLL importiert
-
02-07-2019 - |
Frage
VC2005 verwenden, ich habe 3 Projekte zu erstellen:
- Liba (enthält eine typelib, Ergebnisse in libA.dll): IDL eine Linie
library libA { ...
hat - libb (enthält eine typelib Import Liba, Ergebnisse in libB.dll): IDL eine Linie
importlib( "libA " );
hat - libc (Importe libb): einer der Quelldateien enthält
#import <libB.dll>
die #import <libB.dll>
vom Compiler in der folgenden Art und Weise behandelt wird (nach Dokumentation):
- Suchverzeichnisse von% PATH%
- Suchverzeichnisse von% LIB%
- suchen die "zusätzliche Include-Pfade" (/ I-Compiler-Option)
Wenn libc kompilieren, kann ich das cl.exe deutlich sehen kann die libA.dll auf dem Pfad für ausführbare Dateien finden (mit Filemon.exe)
VC Fehler C4772: # Import von typelib mit einer anderen Abhängigkeit
Allerdings immer noch der Liba-Namespace ist nicht gefunden und alle Verweise auf Liba-Typen werden durch __missing_type__
ersetzt
(edit) In der Zwischenzeit fand ich heraus, das Problem wird nur angezeigt, wenn der Debug-DLLs verwendet wird.
Wer dieses Problem schon einmal gesehen? Und es gelöst?
Lösung 4
Schließlich Found It!
In dem Visual Studio-Projekt, die A.idl Datei in Liba das hatte MkTypeLib unterstützt Einstellung ON. Diese verwarf das Verhalten von dem A-Projekt geerbt. Um alles noch schlimmer zu machen, es nur an in der Debug-Konfiguration war.
Die Folge davon war, dass für jeden
typedef [public] tagE enum { cE1, cE2 } eE;
Dies resultierte in den tagE
nicht in der resultierenden typelib definiert ist. Wenn libb tat es import( "A.dll" )
, alle Verweise auf tagE
mit __missing_type__
ersetzt wurden ...
Andere Tipps
Setzen Sie explizit die Abhängigkeiten des Projekts? Mit anderen Worten: Haben Sie die Lösung in der IDE, so dass Projekt C auf Projekt B abhängen und Projekt B ist abhängig von Projekt A?
Sind Sie mit Typen definiert in Liba von libc? Wenn ja, denke ich, dass Sie brauchen, um direkt Liba aus libc zu importieren, so dass es über LIBA der Typen kennt. COM nicht automatisch die Typbibliotheken verweisen, die sich durch eine andere Art Bibliothek referenziert werden.
ich eine Antwort für Sie nicht haben, aber ich hatte diese Erfahrung mehrmals, und ich möchte teilen, was ich getan habe.
Auf mehreren voneinander unabhängigen Projekten hatte ich Ihre gleiche Szenario. Ich habe versucht, für fast eine Woche in einem Fall die Abhängigkeiten zu lösen, aber ich hatte schließlich meine Verluste, um im Zeitplan zu bleiben zu schneiden. Ich landete eine # include auf der TLH-Datei oben mit (einem Import auf dem DLL Ausführen generiert diese), dann „klassische com“ api-Aufrufe Zeiger auf die Strukturen innerhalb der TLH-Dateien zu erhalten. Der Code ist nicht so sauber, mit zu arbeiten, wie es wäre, wenn Sie die Wrapper-Dateien verwenden können, aber es funktioniert.
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
Sie können etwas „de-verunstalten“ dies durch die CComPtr Wrapper-Vorlage mit der Veröffentlichung zuverlässig von mit destructor tun, wenn es aus dem Geltungsbereich:
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
Beachten Sie, dass der _Application Zeiger ist ein Beispiel für die Verwendung von einem der Strukturen aus einer TLH-Datei.