Cómo enlazar tardíamente el evento COM sin interfaz

Question

Necesito vincular tarde a un objeto COM VB6 de terceros en una aplicación 3.5 C# (para evitar las dependencias de versión que tenemos actualmente). El dll que se proporcionó no es consumible en la mayoría de las formas que no se han cerrado debido a algún error que causa errores cuando tratamos de consumirlo normalmente. Actualmente, estamos usando un contenedor VB6 personalizado que hace que las cosas sean MUY específicas para la versión, sin embargo, he descubierto que puedo usar el enlace tardío para acceder a propiedades y métodos. Ahora, estoy intentando enlazar tarde a eventos, sin embargo, todo lo que he leído dice que necesito heredar de la interfaz del contenedor COM para crear los receptores de eventos necesarios. Here is one such article.

Por lo tanto, mi pregunta es si es posible realizar el manejo de eventos enlazados tarde sin tener ninguna referencia a la DLL en el momento de la compilación?

ACTUALIZACIÓN

Éstos son los errores que tengo con la envoltura de VB6 (que todavía está siendo realizan actualizaciones).

• En OleViewer, me sale

No se pudo descompilar elemento seleccionado el tipo de carga de error/DLL. TYPE_E_CANTLOADLIBRARY ($ 80029C4A)

• En Visual Studio me sale:

No se pudo determinar las dependencias de la referencia COM "3rdPartyDLL". Error al cargar la biblioteca/DLL de tipo. (Excepción de HRESULT : 0x80029C4A (TYPE_E_CANTLOADLIBRARY))

Answer 1

El problema es muy probablemente causado por la plataforma que está utilizando. Ayer tuve un problema similar. Asegúrese de establecer su plataforma de proyecto en x86/x64 cuando se atrase en el enlace de una biblioteca de tipo COM x86/x64.

Lo mismo se aplica al oleview. Use la versión x86/x64 para ver las bibliotecas de tipos x86/x64. (Es posible que necesite instalar el SDK x64 de Windows si está en un sistema x64 para ejecutar el ejecutable correcto).

Answer 2

De here:

me encontré con que el problema es causado cuando el IDL contiene una biblioteca de tipos importlib a .tlb de otro proyecto.

Esto parece crear una dependencia entre un dll y el otro.

Si falta dll dependiente, OLEView se niega a mostrar el dll dependiente , que también se manifiesta al no permitir #import desde el código C++ .

Por lo tanto, examinaría detenidamente las dependencias COM de la DLL en cuestión y me aseguraré de que estén todas registradas también.

También va a añadir:

... porque ambos archivos DLL son codependientes, componentes interactúan entre sí (a través de declaraciones de interfaz sobre el método firmas) y utilizan #import unos de otros biblioteca de tipos.

Por lo tanto, a menos que ambos dlls de destino estén presentes, ninguno puede ser reconstruido. Como se puede imaginar, esto causa un problema terrible cuando intenta reconstruir completamente el proyecto desde cero.

He experimentado con la separación de las definiciones de interfaz en más pequeña archivos IDL ...

---

Editar: aquí es un ejemplo reciente de este problema viene sobre (creo). Tenía una biblioteca de C# exportada a COM. Se hicieron modificaciones a esa biblioteca que cambiaron la interfaz de varias clases, pero el GUID de la biblioteca no se modificó. También see here about risks of AutoDual que estaba en uso.

Aquí está la parte extraña: la DLL VB6 se reconstruyó haciendo referencia a la DLL C# modificada. Compiló bien. sin errores. Pero su typelib era corrupto - OleView no pudo abrirlo, fallando con TYPE_E_CANTLOADLIBRARY. Cambiar el GUID de la DLL de C# fue necesario para obtener la DLL VB6 recompilada con éxito.

Claramente una trampa de VB6/C# interoperabilidad.