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

Question

Tenemos una aplicación GUI MFC monolítica que está llegando al final de su vida útil en C ++. Estamos planeando crear una nueva funcionalidad 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's 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 de una cuadrícula, dirá el customerId y un mensaje para abrir ese cliente en el formulario de cliente de la aplicación MFC.

He investigado un poco, las opciones parecen ser mensajería de Windows, mapeo de memoria, canalizaciones con nombre o algo así como Windows Sockets. En esta etapa, nos estamos inclinando hacia Tuberías con nombre, pero realmente agradeceríamos otros consejos o sugerencias o experiencias de otras personas.

Answer 1

Personalmente, estaría pensando en usar algo como canalizaciones con nombre, 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 el camino de menor resistencia si planea reemplazar los otros bits no .NET de la aplicación con el tiempo.

Answer 2

Elija:

• archivos
• tubos con nombre < - Mi recomendación
• memoria compartida
• enchufes
• COM
• Mensajes de Windows

¿Por qué las tuberías con nombre?

• Le ofrece una forma FIFO de trabajar de forma gratuita (como sockets, pero no como memoria compartida)
• Puede comunicarse fácilmente en ambos sentidos
• Bien soportado en todas las plataformas
• Fácil de usar
• Transferencia y entrega de datos confiables
• Puede ser bloqueante y no bloqueante
• Puede leer datos sin eliminarlos (a diferencia de los sockets)
• Se puede ampliar para incluir una tercera aplicación fácilmente.

En .Net solo use System.IO.Pipes.

En C ++ use CreateNamedPipe y CreateFile.

Answer 3

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 puede usar COM desde cualquier lado.

Answer 4

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

Answer 5

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

Answer 6

¿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.

Answer 7

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, probablemente este sea un buen lugar para comenzar. Si ambas aplicaciones ya son aplicaciones en ventana, ambas ya tienen bucles de mensajes, por lo que ya está casi todo el camino 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 / de 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

Answer 8

Suponiendo que tiene la fuente de la aplicación heredada, vea si no puede compilar todos los " workhorse " codifique como una DLL, luego invoque las funciones / ventanas individuales desde allí. Una vez que tenga eso funcionando, simplemente puede escribir contenedores administrados de C ++ alrededor de las funciones que necesita e invocarlos 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 marco .NET existente en todos los sistemas en los que se ejecutará la aplicación, y COM de lo contrario. Sin embargo, realmente dependería de lo que te resulte más cómodo y familiar. Me gusta la estructura existente de 'llamada de función' de C ++ / CLI y COM (en lugar de construirla con otros protocolos), pero eso soy solo yo.

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