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

Question

У нас есть монолитное приложение MFC GUI, которое подходит к концу своей жизни в C ++. Мы планируем создать новую функциональность в C # и передавать данные между каждым приложением.

Вопрос: каков наилучший подход для передачи данных между C ++ и C #?

Примечания:
Оба конца будут иметь интерфейс GUI и, вероятно, будут нуждаться только в передаче простых данных, таких как Id, и, возможно, иметь механизм, где он указывает другому приложению, какой процесс / функциональность использовать.
Например, одним из приложений будет CRM-система в C #, которая при двойном щелчке по строке в сетке передает слово customerId и сообщение об открытии этого клиента в форме клиента приложения MFC.

Я провел небольшое исследование, кажется, варианты: Windows Messaging, Memory Mapping, Named Pipes или что-то вроде Windows Sockets. На этом этапе мы склоняемся к именованным каналам, но будем очень признательны за другие советы, советы или опыт других людей.

Answer 1

Выберите:

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

Почему именованные трубы?

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

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

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

Answer 2

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

Вероятно, это будет путь наименьшего сопротивления, если вы планируете со временем заменить другие не .NET-биты приложения.

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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

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

Answer 7

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

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

Answer 8

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

Answer 9

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

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

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