Wie zu spät COM-Ereignis ohne Schnittstelle

Question

Ich muss spät Bindung zu einem VB6 COM-Objekt von Drittanbietern in einer C# 3.5-Anwendung (um Versionsabhängigkeiten zu vermeiden, die wir derzeit haben). Die DLL, die zur Verfügung gestellt wurde, ist nicht konsumierbar auf den meisten nicht-späte Art aufgrund eines Fehlers, der Fehler verursacht, wenn wir versuchen, es normal zu verbrauchen. Derzeit verwenden wir einen benutzerdefinierten VB6-Wrapper, der die Sache sehr versionsspezifisch macht. Ich habe jedoch festgestellt, dass ich die Late-Binding verwenden kann, um auf Eigenschaften und Methoden zuzugreifen. Jetzt versuche ich, zu Ereignissen spät zu binden, aber alles, was ich gelesen habe, besagt, dass ich von der COM-Wrapper-Schnittstelle erben muss, um die Ereignissenken zu erstellen, die benötigt werden. Here is one such article.

Also ist meine Frage, ob es möglich ist, spät gebundene Ereignisbehandlung durchzuführen, ohne einen Verweis auf die DLL zur Kompilierzeit zu haben?

UPDATE

Hier sind die Fehler, die ich mit dem VB6-Wrapper haben (die immer noch aktiv aktualisiert werden).

• In OleViewer, bekomme ich

konnte nicht ausgewählt decompile Artikel Fehler beim Laden geben Bibliothek/DLL. TYPE_E_CANTLOADLIBRARY ($ 80029C4A)

• In Visual Studio erhalte ich:

Könnte die Abhängigkeiten der COM Referenz "3rdPartyDLL" nicht bestimmen. Fehler beim Laden der Typbibliothek/DLL. (Ausnahme von HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY))

Answer 1

Das Problem am meisten wird wahrscheinlich durch die Plattform verursacht Sie verwenden. Ich hatte gestern ein ähnliches Problem. Stellen Sie sicher, dass Sie Ihre Projektplattform auf x86/x64 festlegen, wenn Sie eine COM-Typbibliothek x86/x64 spät binden.

Das gleiche gilt für oleview. Verwenden Sie die x86/x64-Version, um x86/x64-Typbibliotheken anzuzeigen. (Möglicherweise müssen Sie das x64 Windows SDK installieren, wenn Sie auf einem x64-System sind, um die korrekte Ausführung zu erhalten).

Answer 2

Von here:

fand ich, dass das Problem verursacht wird, wenn die IDL eine importlib enthält eines anderen TLB typelib des Projekts.

Dies scheint eine Abhängigkeit zwischen einer DLL und der anderen zu schaffen.

Wenn die abhängige DLL fehlt OLEView weigert sich, die abhängige DLL anzuzeigen, die sich auch manifestiert, indem sie #import von C++ Code nicht zulässt.

Daher würde ich die COM-Abhängigkeiten der betreffenden DLL sorgfältig prüfen und sicherstellen, dass sie alle ebenfalls registriert sind.

Es geht auch auf hinzuzufügen:

... weil beide dlls co-abhängig sind, Komponenten von jedem interact (über die Schnittstelle Erklärungen Methode Signaturen) und verwenden #import von jeweils anderen typelib.

Wenn beide Ziel-Dlls nicht vorhanden sind, können beide daher nicht neu erstellt werden. Wie Sie sich vorstellen können, verursacht dies ein schreckliches Problem, wenn Sie versuchen, das Projekt von Grund auf neu zu erstellen .

Ich habe mit Trennung der Schnittstellendefinitionen in kleineren IDL Dateien experimentiert ...

---

Edit: hier ist ein aktuelles Beispiel für dieses Problem zu kommen (ich glaube). Ich hatte eine C# -Bibliothek nach COM exportiert. Es wurden Änderungen an dieser Bibliothek vorgenommen, die die Schnittstelle mehrerer Klassen änderten, aber die Bibliotheks-GUID wurde nicht geändert. Auch see here about risks of AutoDual das war in Benutzung.

Hier ist der seltsame Teil - die VB6-DLL wurde neu erstellt Verweis auf die modifizierte C# -DLL. Es kompiliert. keine Fehler. Aber seine typelib war beschädigt - OleView konnte es nicht öffnen, fehlgeschlagen mit TYPE_E_CANTLOADLIBRARY. Das Ändern der C# -DLL-GUID war erforderlich, um die VB6-DLL erfolgreich neu kompilieren zu lassen.

Offensichtlich eine Falle von VB6/C# Interop.