Acceda al COM x86 desde x64.NET

interop 64bit

Question

Tengo un servidor x64 que, como mis bibliotecas están compiladas en AnyCPU, se ejecuta bajo x64. Necesitamos acceder a un componente COM que está registrado en x86. No sé lo suficiente sobre COM y mis búsquedas de Google no me llevan a ninguna parte.

Pregunta: ¿Puedo usar un enlace de registro simbólico de x64 a x86 para el componente COM? ¿Debo registrar también el componente COM en x64? ¿Puedo (cualquier declaración aquí ...)?

Gracias.

Answer 1

Encontré esta solución, Cómo lidiar con los componentes heredados de 32 bits en Windows de 64 bits, ver 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

Answer 2

Es su componente COM alojado en un servidor COM (es decir, un proceso separado), entonces no tendrá que hacer nada especial, ya que el subsistema COM alejará sus llamadas de su aplicación x64 a la aplicación X86 y viceversa.

Si su componente es un componente COM en proceso, tendrá que replantearse las cosas, ya que un proceso de 64 bits no puede usar 32 bits en los componentes COM del proceso. Podría forzar a su servidor a ejecutarse bajo x86 para que pueda acceder a los componentes (ambos serán procesos de 32 bits). Si no desea hacer esto, deberá ver si hay una versión de x64 de los componentes COM que está utilizando.

Answer 3

Si un componente se ejecuta en x64-native, no puede cargar un servidor COM de 32 bits en proceso, porque es el tipo de proceso incorrecto. Hay un par de soluciones posibles:

1. Si puede, cree una versión de 64 bits del código COM (que, por supuesto, se registraría en el registro de 64 bits). Esta es la solución más limpia, pero puede no ser posible si no tiene el código para el servidor COM.

2. Ejecute su componente .NET como 32-bit x86, en lugar de x64. Supongo que ya ha considerado y rechazado este por alguna razón.

3. Aloje el componente COM fuera del proceso utilizando el sustituto COM DLLhost.exe. Esto hará que las llamadas al servidor COM sean mucho, mucho más lentas (ahora interprocesarán los mensajes de Windows en lugar de las llamadas a funciones nativas), pero de lo contrario será transparente (no tiene que hacer nada especial).

   Probablemente esta no sea una opción si el servidor requiere un proxy-trozo personalizado en lugar de usar el oleaut32 normal (aunque muy raro), ya que no habrá disponible una versión de 64 bits del proxy. Siempre que pueda usar el ordenamiento OLE ordinario, puede registrarlo para la activación sustituta .