Pasar datos entre la aplicación C++ (MFC) y C#

Question

Tenemos una aplicación de interfaz gráfica de usuario MFC monolítica que se acerca al final de su vida útil en C++. Estamos planeando crear nuevas funcionalidades en C# y pasar datos entre cada aplicación.

Pregunta es: ¿Cuál es el mejor enfoque para pasar datos entre C++ y C#?

Notas:
Ambos extremos tendrán una interfaz gráfica de usuario y probablemente solo necesiten pasar datos simples como Id y posiblemente tengan un mecanismo donde indique a la otra aplicación qué proceso/funcionalidad usar.
Por ejemplo, una de las aplicaciones será un sistema CRM en C# que cuando se haga doble clic en una fila en una cuadrícula, diga customerId y un mensaje para abrir ese cliente en el formulario de cliente de la aplicación MFC.

He hecho un poco de investigación, las opciones parecen ser Windows Messaging, Memory Mapping, Named Pipes o algo así como Windows Sockets. En esta etapa nos estamos inclinando hacia Named Pipes, pero realmente apreciaríamos otros consejos o consejos u otras experiencias de la gente.

Answer 1

Personalmente, estaría pensando en utilizar algo así como named pipes, ya que son fáciles de usar desde el lado de C++ y el System.IO.Pipes en el lado de .NET también.

También sería la ruta de menor resistencia si planea reemplazar los otros bits de la aplicación que no son .NET a lo largo del tiempo.

Answer 2

También puede usar P/Invoke desde el lado administrado; esto sería útil si la aplicación MFC tiene una API de C. También puedes usar COM desde cualquier lado.

Answer 3

Las opciones que enumera son ciertamente válidas, pero también podría considerar COM.

Answer 4

Haga su elección:

• archivos
• canalizaciones con nombre < - Mi recomendación
• memoria compartida
• tomas
• COM
• mensajes de Windows

¿Por qué tuberías con nombre?

• le da una forma FIFO de trabajar de forma gratuita (como tomas de corriente, pero no como la memoria compartida)
• puede comunicarse fácilmente en ambos sentidos
• bien soportado en todas las plataformas
• Fácil de usar
• Aprobación y envío de datos confiables
• Puede ser bloqueante y no bloqueante
• Puede leer datos sin eliminar (a diferencia de los enchufes)
• Puede expandirse para incluir una tercera aplicación fácilmente.

En .Net simplemente use System.IO.Pipes.

En C++ use CreateNamedPipe y CreateFile.

Answer 5

Usaría sockets (TCP) - tanto MFC como .NET tienen soporte directo para ellos.

Answer 6

Mis selecciones sería o bien mensajes estándar de ventana (por ejemplo WM_FOO) o DCOM:

• Mensajes trabajarían siempre y cuando la comunicación es muy simple, y la sobrecarga en su puesta en marcha es mínimo. Si puede reducir la comunicación a uno o dos enteros por mensaje, este sería probablemente un buen lugar para comenzar. Si ambas aplicaciones ya tienen aplicaciones con ventana, ambas ya tienen bucles de mensajes, por lo que ya estás casi todo el camino hasta allí.

• DCOM requiere mucha más sobrecarga del programador, pero es bueno que pueda definir una interfaz más rica y evitar tener que convertir mensajes complejos a/desde un formato binario. Si sigue esta ruta, CoRegisterClassObject es el punto de partida para publicar un objeto a través de DCOM. Nunca he intentado hacer esto desde una aplicación C#, pero en principio debería ser completamente posible

Answer 7

¿Realmente necesita dos procesos?

El código C# administrado y sin C++ es perfectamente capaz de operar en el mismo proceso, y con una pequeña capa de C++/CLI administrado, puede reemplazar la complejidad de la comunicación entre procesos con llamadas a funciones simples.

Answer 8

Suponiendo que tiene el origen para la aplicación heredada, vea si no puede compilar todo el código "caballo de batalla" como una DLL, luego invoque las funciones/ventanas individuales desde allí. Una vez que tenga eso funcionando, puede simplemente escribir envolturas de C++ administradas alrededor de las funciones que necesita e invocarlas desde su código C#. Todo el proceso puede tomar menos de un día, si tienes suerte.

Answer 9

Diría C++/CLI si no tiene que preocuparse por el framework .NET existente en todos los sistemas en los que se ejecutará la aplicación, y COM en caso contrario. Sin embargo, realmente dependería de con lo que te sientas más cómodo y familiar. Me gusta la estructura existente de "llamada de función" de C++/CLI y COM (en lugar de compilarla con otros protocolos), pero así soy yo.

Actualmente estoy usando COM para agregar algunas funcionalidades del componente .NET, principalmente debido a la necesidad de seguir funcionando con reembolsos si .NET no está presente, pero eso es específico para mis necesidades donde la implementación máxima es preferible.