64 bits C # con un objeto COM VB6 de 32 bits

Tengo un dll STA VB6 de 32 bits en proceso. Lamentablemente, no puedo hacer nada al respecto. Mi componente C # se beneficia enormemente de ser de 64 bits. ¿Hay alguna forma de llamar / interactuar con este archivo dll de 32 bits de mi proceso de 64 bits? ¿Algún tipo de envoltorio o algo?

No hay forma directa de que puedas hacer esto.

Como no puede portar el dll inproc dll de VB6, le sugiero que escriba un servidor fuera de proceso de 32 bits que implemente las mismas interfaces y haga que deleguen en el código VB6. Entonces, su aplicación de 64 bits puede llamar al servidor fuera de proceso ya que COM se encargará de ordenar los tipos entre los procesos.

No es bonito, pero funcionará.

Este artículo que trata sobre los componentes heredados de 32 bits en Windows de 64 bits lo ayuda a:

Encontré esta solución, mira en el artículo :
• Convertir un tipo de proyecto de en proceso a fuera de proceso
• Usar COM + como anfitrión (este trabajo para mí)
• Usar dllhost como host sustituto

Puede cargar una DLL (por ejemplo) de 32 bits en un sustituto y acceder desde un proceso de 64 bits de la siguiente manera.

Esto funcionará siempre que haya un Marshaller disponible, que generalmente será para un componente con un typelib porque generalmente usan el Marshaller estándar. No funcionará si el objeto requiere un prox / stub personalizado porque las versiones de 64 bits no existirán, o no tendría este problema en primer lugar.

Cómo registrar un componente de 32 bits de terceros para usar desde un cliente de 64 bits

Primero necesitas un AppID. Si el archivo DLL ya tiene un ID de aplicación, debe usar eso. Puede averiguarlo marcando debajo de la clave CLSID para la CoClass que le interesa.

El ejemplo utilizado aquí es las clases Capicom.HashedData y Capicom.EncryptedData . Capicom es solo de 32 bits.

  • AppID: CAPICOM no tiene un AppID, por lo que para el AppID acabo de utilizar el CLSID de la clase EncryptedData.

  • CLSID: necesita una lista del CLSID de cada clase que desea que pueda crear a partir de clientes de 64 bits. En este ejemplo, es solo EncryptedData y HashedData.

  • Registro: cree un archivo de registro que contenga los detalles, según el ejemplo, y cárguelo en el registro.

Debería usar la versión de 32 bits de Regedit para hacer esto, ya que es un componente de 32 bits. Si tiene un componente de 64 bits al que desea acceder desde 32 bits, use el otro. (Esto se debe a la virtualización del registro para la capa de compatibilidad de 32 bits; si utiliza la versión de bits correspondiente de regedit, se ocupa de este problema, al asegurarse de editar la versión virtualizada correcta del registro).

 Windows Registry Editor Version 5.00 ;;; Capicom AppID - just using the Capicom.EncryptedData CLSID ;;; Use default surrogate = empty string [HKEY_CLASSES_ROOT\AppID\{A440BD76-CFE1-4D46-AB1F-15F238437A3D}] "DllSurrogate"="" ;;; Capicom.EncryptedData [HKEY_CLASSES_ROOT\CLSID\{A440BD76-CFE1-4D46-AB1F-15F238437A3D}] AppID="{A440BD76-CFE1-4D46-AB1F-15F238437A3D}" ;;; Capicom.HashedData - use same AppID for all!!!!! [HKEY_CLASSES_ROOT\CLSID\{CE32ABF6-475D-41F6-BF82-D27F03E3D38B}] AppID="{A440BD76-CFE1-4D46-AB1F-15F238437A3D}" 

myComponent-dllhost.reg un archivo myComponent-dllhost.reg y listo.

 c:\windows\sysWow64\regedit.exe "myComponent-dllhost.reg" 

Ahora debería poder acceder a Capicom.HashedData y Capicom.EncryptedData desde los sistemas de comandos / COM de 64 bits.

Notas:

  • Esto solo funciona para los tipos básicos de Automatización OLE. Cualquier objeto compatible con las secuencias de comandos de Windows Scripting Host en VBScript o JavaScript debería estar bien.
  • Solo tiene que agregar el AppID a objetos directamente creables. Eso es básicamente aquellos con una entrada InprocServer32. Los objetos que se generan a partir de fábricas o que solo están disponibles como objetos secundarios no tienen que tener un AppID agregado.
  • Si ya hay un AppID, todo lo que necesita hacer es agregar la entrada de cadena vacía "DllSurrogate" . ¡Eso es!
  • esto NO afectará a los clientes normales de la DLL. Siempre que la bit-ness coincida, continuarán siendo cargados en proceso como antes. La única diferencia que hará es que será posible instanciarlo fuera de proceso de un cliente de bitness diferente.

El componente COM de 32 bits deberá agotarse.

Antes de comenzar a crear un contenedor, compruebe si COM + (Servicios de objetos) lo alojará.