Passando dados entre C ++ (MFC) e app C #

Question

Temos um aplicativo monolítico MFC GUI que está chegando ao fim dele é a vida em C ++. Estamos planejando construir uma nova funcionalidade em C # e passar dados entre cada aplicação.

A pergunta é: Qual é a melhor abordagem para a passagem de dados entre C ++ e C #?

Notas:
Ambas as extremidades terá um final GUI frente e, provavelmente, só precisa passar dados simples, como IDs e, eventualmente, ter um mecanismo onde se indica para o outro aplicativo que processo / funcionalidade para uso.
Por exemplo Uma das aplicações será um sistema de CRM em C # que quando uma linha em uma grade é clicado duas vezes passaria dizer o customerId e uma mensagem para abrir esse cliente no formulário do cliente do aplicativo MFC.

Eu fiz um pouco de pesquisa, as opções parecem ser Windows Messaging, mapeamento de memória, pipes nomeados ou algo como Windows Sockets. Nesta fase estamos inclinando-se para pipes nomeados, mas realmente aprecio outros conselhos ou dicas ou experiências de outras pessoas.

Answer 1

Pessoalmente eu estaria pensando em usar algo como pipes nomeados como eles são fáceis de usar do C ++ lado e as System.IO.Pipes no lado do .NET também.

Além disso, seria o caminho de menor resistência, provavelmente se você está planejando para substituir os outros bits não .NET do aplicativo ao longo do tempo.

Answer 2

Faça a sua escolha:

• arquivos
• pipes <- Minha recomendação
• memória compartilhada
• soquetes
• COM
• mensagens do Windows

Por pipes nomeados?

• Dá-lhe uma maneira FIFO de trabalhar de graça (como soquetes, mas não como memória compartilhada)
• pode se comunicar facilmente em ambos os sentidos
• Bem suportado em todas as plataformas
• Fácil de usar
• Dados confiáveis ??passando e entrega
• Pode ser bloqueio e não de bloqueio
• É possível ler os dados sem remover (ao contrário de sockets)
• Pode ser expandido para incluir um terceiro aplicativo facilmente.

Na Net é só usar System.IO.Pipes.

Em C ++ uso CreateNamedPipe e CreateFile.

Answer 3

Você também pode usar P / Invoke do lado conseguiu - isso seria útil se o aplicativo MFC tem uma API C. Também você pode usar COM de ambos os lados.

Answer 4

As opções que você lista são certamente válida, mas você também pode considerar COM.

Answer 5

Eu usar soquetes (TCP) -. MFC e .NET tem suporte direto para eles

Answer 6

Você realmente precisa de dois processos?

Não gerenciado C ++ e C # código gerenciado é perfeitamente capaz de operar no mesmo processo, e com uma pequena camada de gerenciado C ++ / CLI, você poderia substituir a complexidade da comunicação entre processos com chamadas de função simples.

Answer 7

As minhas escolhas seria ou mensagens de janela padrão (por exemplo WM_FOO) ou DCOM:

• Mensagens iria funcionar, desde que a comunicação é muito simples, ea sobrecarga para a sua criação é mínima. Se você pode ferver a baixo de comunicação a um ou dois inteiros por mensagem, este provavelmente seria um bom lugar para começar. Se ambos os aplicativos já são janelas aplicações, ambos já têm laços de mensagem, então você já maior parte do caminho está lá.

• DCOM requer muito mais programador de cima, mas é bom no que você pode definir uma interface mais rica e evitar ter que converter mensagens complexas para / de forma binária. Se você percorrer esse caminho, CoRegisterClassObject é o ponto de partida para a publicação de um objeto via DCOM. Eu nunca tentei fazer isso a partir de um aplicativo # C, mas, em princípio, deveria ser perfeitamente possível

Answer 8

Assumindo que você tem a fonte para o aplicativo de legado, veja se você não pode compilar todo o código "burro de carga" como um DLL, em seguida, chamar as funções individuais / janelas de lá. Depois de ter esse trabalho, você pode simplesmente escrever Managed wrappers C ++ em torno das funções de que necessita, e invocar os do seu código C #. Todo o processo pode demorar menos de um dia, se você tiver sorte.

Answer 9

Eu diria C ++ / CLI, se você não precisa se preocupar com o .NET framework existente em todos os sistemas do aplicativo será executado, e COM contrário. Seria realmente depende do que você está mais confortável e familiarizado com, no entanto. I como o 'chamada de função' estrutura existente de C ++ / CLI e COM (em oposição a construí-la com outros protocolos), mas isso é só comigo.

Atualmente estou usando COM para adicionar alguma funcionalidade do componente .NET, principalmente devido à necessidade de função ainda com fallbacks se o .NET não está presente, mas que é específico para as minhas necessidades onde a implantação máxima é preferível.