Передача данных между приложением C++ (MFC) и C#

Вы также можете использовать P / Invoke с управляемой стороны - это было бы полезно, если в приложении MFC есть C API. Также вы можете использовать COM с любой стороны.

Перечисленные вами параметры, безусловно, действительны, но вы также можете рассмотреть COM.

Лично я бы подумал об использовании чего-то вроде именованных каналов, поскольку они просты в использовании со стороны C++, а также System.IO.Pipes со стороны .NET.

Это также будет путь наименьшего сопротивления, если вы планируете со временем заменить другие части приложения, не относящиеся к .NET.

Сделайте ваш выбор:

• файлы
• именованные каналы <- Моя рекомендация
• Общая память
• Розетки
• COM
• Сообщения Windows

Почему именованные каналы?

• Предоставляет вам способ работы с FIFO бесплатно (как сокеты, но не как общая память)
• Может легко общаться в обе стороны
• Хорошо поддерживается на всех платформах
• Легко использовать
• Надежная передача и доставка данных
• Может быть блокирующим и неблокирующим
• Может читать данные без удаления (в отличие от сокетов)
• Может быть легко расширен для включения третьего приложения.

В .Net просто используйте System.IO.Pipes.

В C++ используйте CreateNamedPipe и CreateFile.

Я бы использовал сокеты (TCP) - и MFC, и .NET имеют прямую поддержку для них.

Я бы выбрал стандартные оконные сообщения (например, WM_FOO) или DCOM:

• Сообщения будут работать до тех пор, пока связь очень проста, а накладные расходы на ее настройку минимальны. Если вы можете свести общение к одному или двум целым числам на сообщение, это, вероятно, будет хорошим местом для начала. Если оба приложения уже являются оконными приложениями, у них обоих уже есть петли сообщений, так что вы уже почти на своем пути.

• DCOM требует гораздо больше накладных расходов программиста, но это приятно тем, что вы можете определить более богатый интерфейс и избежать необходимости преобразовывать сложные сообщения в / из двоичной формы. Если вы пойдете по этому пути, CoRegisterClassObject станет отправной точкой для публикации объекта через DCOM. Я никогда не пробовал делать это из приложения на C#, но в принципе это должно быть вполне возможно.

Вам действительно нужны два процесса?

Неуправляемый код C++ и управляемый код C# вполне могут работать в одном процессе, и с небольшим уровнем управляемого C++ / CLI вы можете заменить сложность межпроцессного взаимодействия простыми вызовами функций.

Предполагая, что у вас есть исходный код для устаревшего приложения, посмотрите, не можете ли вы скомпилировать весь код «рабочей лошадки» как DLL, а затем вызвать оттуда отдельные функции / окна. После того, как вы это заработаете, вы можете просто написать управляемые оболочки C++ вокруг необходимых вам функций и вызывать их из вашего кода C#. Если повезет, на весь процесс уйдет меньше суток.

Я бы сказал C++ / CLI, если вам не нужно беспокоиться о платформе .NET, существующей во всех системах, на которых будет работать приложение, и о COM в противном случае. Однако это действительно будет зависеть от того, что вам наиболее удобно и с чем вы знакомы. Мне нравится существующая структура «вызова функций» C++ / CLI и COM (в отличие от построения ее с помощью других протоколов), но это только мне.

В настоящее время я использую COM для добавления некоторых функций компонента .NET, в основном из-за необходимости по-прежнему работать с резервными вариантами, если .NET отсутствует, но это относится к моим потребностям, когда предпочтительнее максимальное развертывание.