How to latebind COM event without interface

▲
5
▼

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))

c#
vb6
.net-3.5
late-binding
oleview
asked on Stack Overflow Oct 10, 2012 by Justin Pihony • edited Feb 4, 2019 by StayOnTarget

2 Answers

▲
0
▼

The problem is most probably caused by the platform you are using. I just had a similar problem yesterday. Make sure that you are setting your project platform to x86 / x64 when you are late binding a x86/x64 COM type library.

The same applies to oleview. Use the x86/x64 version to view x86/x64 type libraries. (Possibly you need to install the x64 Windows SDK if you are on an x64 system to get the correct executeable).

answered on Stack Overflow Feb 12, 2013 by Carsten
▲
0
▼

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.

answered on Stack Overflow Mar 30, 2017 by StayOnTarget • edited Jul 6, 2017 by StayOnTarget

User contributions licensed under CC BY-SA 3.0