Pasar datos entre la aplicación C++(MFC) y C#
ipc (9)
¿Realmente necesitas dos procesos?
El código C # no administrado y C # administrado 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.
Tenemos una aplicación monolítica de GUI de MFC 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.
La 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 de CRM en C # que cuando se haga doble clic en una fila en una grilla, pase, diga customerId y un mensaje para abrir a ese cliente en el formulario de cliente de la aplicación MFC.
He investigado un poco, 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.
Elige tu opción:
- archivos
- tubos con nombre <- Mi recomendación
- memoria compartida
- tomas de corriente
- COM
- Mensajes de Windows
¿Por qué tuberías con nombre?
- Te da una forma FIFO de trabajar gratis (como los sockets, pero no como la memoria compartida)
- Puede comunicarse fácilmente en ambos sentidos
- Bien soportado en todas las plataformas
- Fácil de usar
- Transmisión de datos y entrega confiables
- Puede ser bloqueante y no bloquear
- Puede leer datos sin eliminar (a diferencia de los enchufes)
- Se puede expandir para incluir una tercera aplicación fácilmente.
En .Net simplemente use System.IO.Pipes.
En C ++ use CreateNamedPipe y CreateFile.
Las opciones que enumera son ciertamente válidas, pero también podría considerar COM.
Mis selecciones serían mensajes de ventana estándar (por ejemplo, WM_FOO) o DCOM:
Los mensajes funcionarían siempre que la comunicación sea muy simple y la sobrecarga en la configuración sea mínima. 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 una forma binaria. 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
Personalmente, estaría pensando en usar algo como named pipes, ya que son fáciles de usar desde el lado de C ++ y 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.
Suponiendo que tiene la fuente 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.
También puede usar P / Invoke desde el lado administrado; esto sería útil si la aplicación MFC tiene una API C. También puedes usar COM desde cualquier lado.
Usaría sockets (TCP): tanto MFC como .NET tienen soporte directo para ellos.
Yo 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 errores si .NET no está presente, pero eso es específico para mis necesidades donde es preferible la implementación máxima.