C++ - Linking und COM-Registrierung Problem

Question

Ich habe eine neue Bibliothek zu meiner Anwendung (mehrere Projekte-DLLs) hinzugefügt - SQLite, um einige im Speicher Caching durchzuführen. Es gibt nur eine Bibliothek/Projekt, die von dieser Änderung betroffen ist - Lib1.

Ein Build läuft gut. Alle Bibliotheken werden erfolgreich erstellt und es werden keine Fehler gemeldet, einschließlich einiger Com-Objekte.

Wenn ich versuche, die com Objekte zu registrieren, bekomme ich die DLL konnte nicht geladen werden. Stellen Sie sicher, dass alle erforderlichen Anwendungslaufzeitdateien und andere abhängige DLLs im Verzeichnis der Komponenten-DLL oder im Systempfad verfügbar sind. Nachricht. Aber alle Bibliotheken sind am selben Ort. Und alle sind auf dem Weg. Eine Kopie dieses Projekts erstellt und registriert sich gut (ohne die wenigen Änderungen, die für SqlLite vorgenommen wurden). Dependency Walker meldet keine Probleme

Seltsamerweise, wenn ich versuche, die DLL des com-Objekts (mit regsvr32) zu registrieren, funktioniert es gut. Außerdem habe ich eine andere Bibliothek, die von Lib1 abhängig ist (nicht von SqlLite), die auch nicht geladen werden kann.

Irgendwelche Ideen?

Danke, A'z

Answer 1

Sie können Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) verwenden, um den Prozessnamen regsvr32.exe zu filtern, um alle Datei- und Registrierungszugriffe anzuzeigen.

Verwenden Sie immer den vollständigen Pfad zu Ihrer COM-DLL, wenn Sie Regsvr32-Befehle ausgeben, wenn Sie dieselbe DLL irgendwo im Pfad haben (zum Beispiel C: \ Windows \ System32) Regsvr32 wird die andere DLL und nicht die eine verwenden in Ihrem aktuellen Verzeichnis.

Ein weiterer Trick wäre die Verwendung von "rundll32 your-com-dll, DllRegisterServer". Bei fehlenden DLLs wird angezeigt, welche DLL fehlt, anstatt nur zu sagen, dass LoadLibrary fehlgeschlagen ist.

Bearbeiten: Was meinen Sie mit "Wenn ich versuche, die com-Objekte zu registrieren"? Wie machst du das? Ich frage, weil Sie sagen, dass regsvr32 auf der DLL, die tatsächlich diese com-Objekt implementiert funktioniert gut.

Answer 2

das Dependency Walker-Tool verwenden, was andere DLLs der COM-Server auf verlässt sich herauszufinden. Überprüfen Sie dann die ausführbaren Pfade, die in Visual Studio eingestellt sind (Extras -> Optionen -> Projekte -> Verzeichnisse (glaube ich)). Beachten Sie, dass VS nicht die PATH-Umgebungsvariable des Systems verwendet - sie verwendet das, was auf der Options-Seite festgelegt ist. Wenn der Pfad zu den Abhängigkeiten dort nicht aufgeführt ist, würde die Registrierung fehlschlagen, selbst wenn Sie regsvr32 von der Befehlszeile aus verwenden würden gelingen.

Answer 3

Und so verdickt sich die Handlung !!!!

Ich habe eigentlich eingegrenzt, um die Codezeile, die dieses Verknüpfungsproblem verursacht. In der geänderten Bibliothek (LIB1) habe ich eine neue Klasse A1 hinzugefügt, die von einer vorhandenen Klasse A erbt. Wenn ich eine vorhandene Klasse B ändern, die von A erbte, um jetzt von A1 zu erben - das ist, wenn das Problem ist verursacht. Klasse B befindet sich in einer lib3.

Ich habe das nur verifiziert, wenn ich die Vererbung ändere, nur dann tritt das Problem auf !!!

Ich habe File-Mon auf Regsvr32 beim Laden erfolgreich und beim Scheitern verwendet. Ich buggle, um den Unterschied zu finden! Morgen früh werde ich Process Monitor ausprobieren und sehen, ob es hilft.

noch verzweifelt um Hilfe, A'z

Answer 4

hmm ... wie Christian fragt, wie sonst versuchen, die Objekte zu registrieren, wenn regsvr32.exe gelingt?

der Rundll32.exe-Hinweis ist auch gut. Haben Sie versucht, in einem Debugger durch DllRegisterServer zu gehen, um genau zu sehen, wenn es fehlschlägt? Das klingt wie ein potenzieller Laufzeitfehler, wenn depends.exe nichts enthüllt.

btw, wenn ich für den genauen Fehlertext google ich sehe: http://social.msdn.microsoft.com/forums/en-US/sqldataaccess/thread/402c1767-cf1d-42f0-aec9-e0169dbf1083/, aber ich nehme an, Sie haben wahrscheinlich schon diese Suche gemacht und finde es nicht hilfreich :)