La mejor manera de llamar al código no administrado de 32 bits del código administrado de 64 bits utilizando un contenedor de código administrado

Question

La frecuencia con la que me encuentro con la situación en la que tengo que llamar al código nativo de 32 bits de un proceso administrado de 64 bits está aumentando a medida que las máquinas y aplicaciones de 64 bits se vuelven predominantes. No quiero marcar mi aplicación como de 32 bits y no puedo obtener versiones de 64 bits del código que se está llamando.

La solución que uso actualmente es crear calzas C++ COM que se cargan sin procesar para realizar las llamadas de 32 bits del proceso de 64 bits.

Esta solución COM shim funciona bien y las llamadas de proceso cruzadas se manejan detrás de escena por COM, lo que minimiza la sobrecarga de este enfoque.

Sin embargo, me gustaría mantener todo el nuevo desarrollo que llevamos a cabo usando C# y nos preguntamos si hay marcos que minimicen la sobrecarga de hacer esto. Miré IPCChannel pero creo que este enfoque no es tan claro como la solución COM shim.

gracias, Ed

Answer 1

Tuve el mismo problema y mi solución fue usar remoting. Básicamente, el proyecto consistía en:

• independiente de la plataforma CalculatorRemote.dll biblioteca con
  • CalculatorNative clase estática interna con x32 P/invocar métodos
  • RemoteCalculator clase derivada de MarshalByRefObject que utiliza métodos nativos de CalculatorNative;
• principal C# biblioteca independiente de la plataforma (por ejemplo Calculator.dll), haciendo referencia a CalculatorRemote.dll, con Calculator clase que fue privada utilizando singleton de la clase RemoteCalculator para invocar funciones x32 cuando sea necesario;
• x32 aplicación de consola que alojó RemoteCalculator de CalculatorRemote.dll para consumir por Calculator.dll a través de IpcChannel.

lo tanto, si la aplicación principal se inició en el modo de 64 bits que estaba generando una aplicación RemoteCalculator anfitrión y utiliza remoted RemoteCalculator ejemplo. (Cuando en x32 solo usó una instancia local de RemoteCalculator). La parte engañosa fue decirle a la aplicación calculadora-host que se apagara.

Creo que esto es mejor que usar COM porque:

• Usted no tiene que registrarse clases COM en cualquier lugar;
• Interoperar con COM debe ser más lento que .NET remoto;
• A veces, si algo va mal en el lado COM, debe reiniciar la aplicación para recuperarla; (posiblemente no estoy muy familiarizado con COM)
• Al ejecutar en modo x32, no habrá ninguna penalización de rendimiento con la comunicación remota; todos los métodos se invocarán en el mismo dominio de aplicación.

Answer 2

Prácticamente la única respuesta está fuera del proceso de comunicación. Podría crear un proyecto .NET que sea un ejecutable de 32 bits que haga todas las llamadas de 32 bits necesarias y se comunique con él a través de los mensajes de Windows, WCF, Canalizaciones con nombre, archivos mapeados de memoria (4.0), etc. Estoy bastante seguro Así es como Paint.NET realiza su WIA (adquisición de imágenes de Windows) a partir de un proceso de 64 bits.

En el caso de PDN, simplemente pasan el nombre del archivo que esperan como resultado, pero la comunicación más compleja no es difícil. Podría ser una mejor forma de ir dependiendo de lo que estés haciendo.