How to latebind COM event without interface

Question

I need to late bind to a 3rd party VB6 COM object in a 3.5 C# application (to avoid version dependencies that we currently have). The dll that was provided is not consumable in most non-latebound ways due to some bug that causes errors when we try to consume it normally. Currently, we are using a custom VB6 wrapper that makes things VERY version specific, however I have found that I can use late-binding to access properties and methods. Now, I am trying to late-bind to events, however everything I have read says that I need to inherit from the COM wrapper's interface to create the event sinks that are needed. Here is one such article.

So, my question is whether it is possible to perform late-bound event handling without having any reference to the dll at compile time?

UPDATE

Here are the errors I have with the VB6 wrapper (Which is still being actively updated).

• In OleViewer, I get

Could not decompile selected item Error loading type library/DLL. TYPE_E_CANTLOADLIBRARY ($80029C4A)

• In Visual Studio I get:

Could not determine the dependencies of the COM reference "3rdPartyDLL". Error loading type library/DLL. (Exception from HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY))

Answer 1

From here:

I found that the problem is caused when the IDL contains an importlib to another project's .tlb typelib.

This seems to create a dependency between one dll and the other.

If dependant dll is missing OLEView refuses to display the dependent dll, which also manifests itself by not allowing #import from C++ code.

Therefore I would look carefully at the COM dependencies of the DLL in question and make sure they are all registered as well.

It also goes on to add:

...because both dlls are co-dependent, components from each interact (via interface declarations on method signatures) and use #import from each others typelib.

Therefore, unless both target dlls are present, neither can be rebuilt. As you can imagine, this causes a terrible problem when you try to completely rebuild the project's from scratch.

I've experimented with separating the interface definitions into smaller IDL files...

---

Edit: here's a recent example of this problem coming about (I believe). I had a C# library exported to COM. Modifications to that library were made which changed the interface of several classes, but the library GUID was not changed. Also see here about risks of AutoDual which was in use.

Here's the odd part - the VB6 DLL was rebuilt referencing the modified C# DLL. It compiled fine. no errors. But its typelib was corrupt - OleView couldn't open it, failing with TYPE_E_CANTLOADLIBRARY. Changing the C# DLL GUID was necessary to get the VB6 DLL recompiled successfully.

Clearly a pitfall of VB6 / C# interop.