Meu aplicativo não é gerenciado.Por onde começo a introduzir o código gerenciado?

Question

Todo o meu aplicativo (que é bastante grande, com um executável de 20 MB) está escrito em C++ não gerenciado.Como posso ver claramente as vantagens de usar código gerenciado, quero começar a introduzir código gerenciado em meu aplicativo, mas por onde começo?

Posso facilmente começar a usar C++/CLI e vinculá-lo ao restante do meu aplicativo?(embora a sintaxe C++/CLI pareça bastante 'exótica').

Ou é melhor mudar para C#, mas qual é a melhor maneira de 'vincular' isso ao meu código C++ não gerenciado?

Faz sentido compilar todo o meu código C++ com a opção /clr?Isso vai funcionar?

Devo me preocupar com a triagem?Isso gera uma sobrecarga ou posso alternar entre gerenciado e não gerenciado sem penalidade de desempenho (assim como fiz há 20 anos ao misturar Fortran e C).O desempenho é muito importante na minha aplicação, pois é uma aplicação científica que às vezes processa vários Gigabytes de memória.

Ou só faz sentido redesenhar a interface do usuário, escrever isso apenas em C# e manter o restante do meu aplicativo (lógica de cálculo, lógica de negócios, interface de banco de dados, ...) em C++ não gerenciado?

Como meu aplicativo às vezes precisa lidar com vários Gigabytes de memória, tenho uma variante de 64 bits.É fácil ter código gerenciado de 64 bits?O coletor de lixo ainda seria eficiente se tanta memória fosse usada?

Simplesmente indique:por onde eu começo?

Patrício

Answer 1

No momento, considere essa pergunta fechada.

Percebi que a resposta não está misturando C ++ e C#, mas acertar a arquitetura em primeiro lugar.

Se a arquitetura estiver correta e separada onde precisar ser separada, então alterar partes do aplicativo por outros módulos (externo, outro idioma, ...) deve ser mais fácil.

Em relação aos problemas de desempenho durante o marechalling, teremos que esperar até que o .NET amadureça ainda mais.

Answer 2

Crie um perfil do aplicativo, decida em quais pontos de integração você pode sair da linha de lógica C# e entrar em C++ e vice-versa.Organize-os em um plano para que um padrão de design Façade se mova pelo sistema substituindo gradualmente C++ por C#.A principal preocupação é o custo de CPU e memória ao decidir mudar de idioma em cada fachada/interface candidata.

Você desejará ser capaz de incorporar edições para que seja melhor ter um conjunto de código-fonte e repositório de código-fonte para o código C++ original e outro conjunto e repositório para a fachada mais o C#.

Então, à medida que o trabalho de melhorias/manutenção chega na bandeja de entrada, você o aplica a ambas as bases de código e tenta garantir que a fachada se mova pelo sistema, começando com o código com menor probabilidade de ser alterado em melhorias ou manutenção para minimizar a duplicação do trabalho de alterações. .

Idealmente, estruture seu trabalho para que você possa reverter a fachada para voltar a 100% C++ rapidamente, caso encontre um obstáculo.

Para testar se alguns módulos C++ particularmente inescrutáveis ​​podem ser separados em uma parte C++ e uma parte C#, execute-os em dois processos Win32 C++ diferentes, comunicando-se usando um canal ou soquete.Dessa forma, você terá uma ideia melhor se há problemas com gerenciamento de memória ou desempenho que precisam ser corrigidos antes de dividir a cadeia de chamadas nesse ponto.

Answer 3

Fazemos exatamente o que você descreveu em um aplicativo de missão crítica usada por milhares de usuários. Basicamente, mantivemos o aplicativo existente como está, portanto o executável ainda é um executável 100% não gerenciado (não C ++/CLI). Em seguida, colocamos todo o nosso novo código C# em DLLs .NET, que consiste em objetos de negócios, controles de usuário e código da GUI, etc ....

Basicamente, todo o novo código está escrito em C#. Temos 1 DLL que é C ++/CLI que é apenas cola. Isso nos permite integralizar facilmente entre o código gerenciado e não gerenciado, sem precisar fazer o código C ++ existente CLR. Isso limita a quantidade de código C ++/CLI que temos que escrever. O código nativo fala com o código do modo misto, que pode conversar com o código gerenciado. A DLL do modo misto pode conectar eventos nas classes C# para que o código C# possa simplesmente demitir o evento para se comunicar com a C ++/CLI (que pode conversar com o código nativo).

Também podemos hospedar .Net UserControls em um aplicativo C ++ existente (o WinForms é apenas um invólucro em torno do Winapi de qualquer maneira, então funciona muito bem).

Isso funciona muito bem e permite manter seu código existente sem precisar reescrever toda a GUI em C#.