Passage de données entre l'application C ++ (MFC) et C #

Question

Nous avons une application graphique monolithique MFC qui approche de la fin de sa vie en C ++. Nous prévoyons de créer de nouvelles fonctionnalités en C # et de transmettre des données entre chaque application.

La question est la suivante: quelle est la meilleure approche pour transmettre des données entre C ++ et C #?

Notes:
Les deux extrémités auront une interface graphique et n'auront probablement besoin que de transmettre des données simples telles que les identifiants et éventuellement d'un mécanisme permettant d'indiquer à l'autre application le processus / les fonctionnalités à utiliser.
Par exemple, l’une des applications sera un système de gestion de la relation client en C # qui, lorsqu’une ligne dans une grille est double-cliquée, passe, indique le customerId et un message pour ouvrir ce client dans le formulaire client de l’application MFC.

J'ai fait un peu de recherche, les options semblent être Windows Messaging, Memory Mapping, Named Pipes ou quelque chose comme Windows Sockets. À ce stade, nous nous tournons vers Named Pipes, mais nous aimerions vraiment recevoir d’autres conseils ou astuces ou les expériences d’autres peuples.

Answer 1

Personnellement, je penserais à utiliser quelque chose comme les canaux nommés, car ils sont faciles à utiliser du côté C ++ et System.IO.Pipes du côté .NET également.

Ce serait également le chemin de la moindre résistance probablement si vous envisagez de remplacer les autres bits non .NET de l'application au fil du temps.

Answer 2

Faites votre choix:

• fichiers
• tubes nommés < - Ma recommandation
• mémoire partagée
• sockets
• COM
• messages Windows

Pourquoi les pipes nommées?

• vous donne une méthode de travail FIFO gratuite (comme les sockets, mais pas comme la mémoire partagée)
• Peut facilement communiquer dans les deux sens
• Bien pris en charge sur toutes les plateformes
• Facile à utiliser
• Transmission et transmission fiables des données
• Peut être bloquant et non bloquant
• Peut lire des données sans les supprimer (contrairement aux sockets)
• Peut être étendu pour inclure facilement une troisième application.

En .Net, utilisez simplement System.IO.Pipes.

En C ++, utilisez CreateNamedPipe et CreateFile.

Answer 3

Vous pouvez également utiliser P / Invoke à partir du côté géré - cela serait utile si l'application MFC dispose d'une API C. Vous pouvez aussi utiliser COM de part et d’autre.

Answer 4

Les options que vous avez répertoriées sont certes valables, mais vous pouvez également envisager COM.

Answer 5

J'utiliserais des sockets (TCP) - MFC et .NET les prennent directement en charge.

Answer 6

Avez-vous vraiment besoin de deux processus?

Le code non géré C ++ et le code C # géré sont parfaitement capables de fonctionner dans le même processus et, avec une petite couche de C ++ / CLI managée, vous pouvez remplacer la complexité de la communication interprocessus par de simples appels de fonctions.

Answer 7

Mes choix seraient des messages de fenêtre standard (par exemple, WM_FOO) ou DCOM:

• Les messages fonctionneraient tant que la communication est très simple et que le temps système nécessaire à sa configuration est minimal. Si vous pouvez réduire la communication à un ou deux nombres entiers par message, ce serait probablement un bon point de départ. Si les deux applications sont déjà des applications fenêtrées, elles comportent déjà des boucles de message. Vous y êtes donc déjà presque.

• DCOM nécessite beaucoup plus de temps système, mais il est agréable de pouvoir définir une interface plus riche et d’éviter de convertir des messages complexes en forme binaire. Si vous choisissez cette voie, CoRegisterClassObject est le point de départ de la publication d’un objet via DCOM. Je n'ai jamais essayé de le faire depuis une application C #, mais en principe, cela devrait être tout à fait possible

Answer 8

En supposant que vous ayez le code source de l'application existante, voyez si vous ne pouvez pas compiler tous les & "; bêtes de somme &"; code en tant que DLL, puis appelez les fonctions / fenêtres individuelles à partir de là. Une fois que cela fonctionne, vous pouvez simplement écrire des wrappers Managed C ++ autour des fonctions dont vous avez besoin et les appeler à partir de votre code C #. L'ensemble du processus peut prendre moins d'une journée, si vous êtes chanceux.

Answer 9

Je dirais C ++ / CLI si vous n'avez pas à vous soucier du framework .NET existant sur tous les systèmes sur lesquels l'application sera exécutée et de COM autrement. Cela dépend toutefois de ce avec quoi vous êtes le plus à l'aise et familier. J'aime la structure existante "d'appel de fonction" de C ++ / CLI et COM (par opposition à sa construction avec d'autres protocoles), mais ce n'est que moi.

J'utilise actuellement COM pour ajouter des fonctionnalités de composant .NET, principalement en raison de la nécessité de continuer à utiliser des substitutions si .NET n'est pas présent, mais cela est spécifique à mes besoins pour lesquels un déploiement maximal est préférable.