Mon application est non gérée. Où puis-je commencer à introduire du code managé?

Question

Toute mon application (qui est plutôt grande, avec un exécutable de 20 Mo) est écrite en C++ non géré. Parce que je peux clairement voir les avantages de l'utilisation du code managé, je veux commencer à introduire du code managé dans mon application, mais par où commencer? Est-ce que je peux facilement commencer à utiliser C++/CLI et le lier au reste de mon application? (bien que la syntaxe C++/CLI semble plutôt "exotique").

Ou est-il préférable de passer en C#, mais quelle est la meilleure façon de «lier» cela avec mon code C++ non managé?

Est-ce qu'il est logique de compiler tout mon code C++ avec l'option/clr? Est-ce que ça va marcher?

Est-ce que je dois m'inquiéter de l'assemblage? Est-ce que cela donne un surcoût ou est-ce que je peux basculer entre géré et non géré sans une pénalité de performance (tout comme je l'ai fait il y a 20 ans lors du mix fortran et C). La performance est vraiment importante dans mon application car c'est une application scientifique qui traite parfois plusieurs gigaoctets de mémoire.

Ou est-ce logique de repenser l'interface utilisateur, et seulement écrire en C#, et garder le reste de mon application (logique de calcul, logique métier, interface de base de données, ...) en C++ non managé?

Depuis mon application doit parfois gérer plusieurs gigaoctets de mémoire, j'ai une variante 64 bits. Est-il facile d'avoir du code managé 64 bits? Woudl le garbage collector sera-t-il encore efficace si on utilise autant de mémoire?

Indiquez simplement: par où commencer?

Patrick

Answer 1

Pour le moment, posez cette question comme étant fermée. Je me suis rendu compte que la réponse n'est pas de mélanger C++ et C#, mais d'obtenir l'architecture correcte en premier lieu.

Si l'architecture est correcte, et séparée là où elle doit être séparée, la modification des parties de l'application par d'autres modules (externes, autre langue, ...) devrait être plus facile. En ce qui concerne les problèmes de performance pendant le marshalling, nous devrons attendre jusqu'à ce que .Net soit plus mature.

Answer 2

Profil de l'application, décider à quel point l'intégration, vous pouvez casser la C# ligne de la logique et de briser en C++ et vice-versa. Disposez-les dans un plan pour faire évoluer le motif de conception de facade à travers le système en remplaçant progressivement C++ par C#. Le coût du CPU et de la mémoire est une préoccupation majeure lorsque l'on décide de changer de langue à chaque façade/interface candidate. Vous voudrez être en mesure d'incorporer les modifications de sorte que vous préféreriez un ensemble de code source et un référentiel de code source pour le code C++ original et un autre ensemble et référentiel pour la façade plus le C#. Ensuite, au fur et à mesure des améliorations/travaux de maintenance, vous l'appliquez aux deux bases de code et vous vous assurez que la façade se déplace dans le système en commençant par le code le moins susceptible de changer d'améliorations ou de maintenance. le doublement des changements fonctionne.

De manière idéale, structurez votre travail de manière à ce que vous puissiez restaurer la façade pour revenir à 100% C++ à la baisse d'un chapeau si vous rencontrez un problème.

Pour tester si un couple de modules C++ particulièrement inscriptibles peut être séparé en une pièce C++ et une pièce C#, exécutez-les dans deux processus Win32 C++ différents communiquant à l'aide d'un tube ou d'un socket. De cette façon, vous aurez une meilleure idée de la présence de problèmes de gestion de la mémoire ou de performances qui doivent être résolus avant de pouvoir diviser la chaîne d'appel à ce stade.

Answer 3

Nous faisons exactement ce que vous avez décrit dans une application critique utilisée par des milliers d'utilisateurs. Fondamentalement, nous avons gardé l'application existante telle quelle, donc l'exécutable est toujours un exécutable non géré à 100% (pas C++/CLI). Nous mettons ensuite tout notre nouveau code C# dans les DLL .NET qui se composent d'objets métier, de contrôles utilisateur et de code gui, etc ....

Fondamentalement, tout le nouveau code est écrit en C#. Nous avons 1 dll qui est C++/CLI qui est juste de la colle. Cela nous permet d'interagir facilement entre le code géré et non géré, sans avoir à faire le code C++ existant. Cela limite la quantité de code C++/CLI que nous devons écrire. Le code natif parle au code en mode mixte, qui peut parler au code managé. La DLL en mode mixte peut accrocher des événements sur les classes C# afin que le code C# puisse simplement déclencher l'événement pour communiquer avec le C++/CLI (qui peut parler au code natif).

Nous pouvons également héberger des UserControls .NET dans une application C++ existante (WinForms n'est qu'un wrapper autour de WINAPI, donc ça marche plutôt bien).

Cela fonctionne très bien et vous permet de conserver votre code existant sans avoir à réécrire l'intégralité de l'interface graphique en C#.