stratégie de migration recommandée pour le projet de C dans Visual Studio 6

Question

Pour une grande application écrite en C ++ en utilisant Visual Studio 6, ce qui est la meilleure façon de se déplacer dans l'ère moderne?

Je voudrais adopter une approche progressive où nous passons lentement des parties du code et écrire de nouvelles fonctionnalités en C # par exemple et compilons que dans une bibliothèque ou dll qui peut être référencé à partir de l'application héritée.

Est-ce possible et quelle est la meilleure façon de le faire?

Modifier : À ce stade, nous sommes limités aux éditions Express que je crois ne permettent pas l'utilisation des bibliothèques MFC qui sont fortement utilisés dans notre application actuelle. Il est également tout à fait une grande application avec beaucoup de dépendances matérielles, donc je ne pense pas une migration de gros est dans les cartes.

Edit2 : Nous avons examiné l'écriture des composants COM emballés en C # mais ayant aucune expérience de ce COM est effrayant et compliqué. Est-il possible de générer un dll C # avec une interface droite C avec toute la bonté gérée cachée à l'intérieur? Ou est-COM est un mal nécessaire?

Answer 1

Face à la même tâche, ma stratégie serait quelque chose comme:

1. Identifier ce que nous espérons gagner en passant à 2010 le développement - il pourrait être

   • une meilleure assurance de la qualité: les tests unitaires, se moquant font partie des outils de développement modernes
   • UI Slicker. WPF offre un look moderne et la sensation
   • la productivité: dans certaines régions, le développement .NET est plus productif que le développement C ++
   • Support:. De nouveaux outils sont pris en charge avec des améliorations et corrections de bugs

2. Identifier les parties du système ne gagneraient à être déplacés vers C #:

   • l'accès au matériel, le code algorithmiques bas niveau
   • à peu près plus sur mesure le code de travail non-UI - pas de point jeter si cela fonctionne déjà

3. Identifier les parties de la nécessité du système à migrer vers c #. Pour ces pièces, assurez-vous que la mise en œuvre actuelle en C ++ est découplée et donc modulaire que ces pièces peuvent être permutées. Si l'application est un monolithe, alors un travail considérable sera nécessaire refactorisation l'application afin qu'il puisse être brisé et de sélectionner des morceaux réimplémenta c #. (Il est possible de ne rien refactoring, au lieu simplement se concentrer sur la mise en œuvre de nouvelles fonctionnalités d'application en C #.)

4. Maintenant que vous avez identifié quelles parties restent en C ++ et quelles parties seront mises en œuvre c #, (ou tout simplement stipuler que les nouvelles fonctionnalités sont en c #), puis se concentrer tour à tour à la façon d'intégrer c # et C ++ dans un solution unique

   • l'utilisation des emballages COM - si votre projet existant ++ C fait bon usage de OO, ce qui est souvent pas aussi difficile que cela puisse paraître. Avec MSVC 6, vous pouvez utiliser les classes ATL pour exposer vos classes en tant que composants COM.
   • Intégrer directement le code natif et c #. L'intégration de « l'héritage » code compilé nécessite une DLL intermédiaire -. Voir pour plus de détails

Le mélange de l'interface utilisateur MFC et c # UI est probablement pas achieveable, et non adviseable soit comme il produirait un mélange de l'interface utilisateur de deux styles distincts (années 1990 gris et l'ambiance 2010). Il est plus simple de se concentrer sur la réalisation de la migration progressive, comme la mise en œuvre nouveau code d'application en C # et appeler à partir du code C ++ natif. Cela permet de maintenir la quantité de petits migrée code c # pour commencer. Comme vous obtenez plus dans le développement 2010, vous pouvez alors prendre les plus gros morceaux qui ne peuvent pas être migrés progressivement, comme l'interface utilisateur.

Answer 2

Je voudrais prendre une incrémentiel approche où nous avançons lentement portions du code

C'est la seule façon réaliste de le faire.

D'abord, quel genre de contrôle de version utilisez-vous? (Si vous utilisez branchement contrôle de version qui vous permet de faire des expériences et de voir ce qui fonctionne, tout en minimisant le risque de compromettre votre code, d'autres sont OK aussi, mais vous devez être très prudent en fonction de ce que vous utilisez) <. / p>

Modifier : Je viens de voir que vous utilisez SVN. Il peut être worthwile de passer à Mercurial ou git si vous avez la liberté de le faire (le changement fournit un saut quantique dans ce que vous pouvez faire avec la base de code).

et écrire de nouvelles fonctionnalités en C # pour exemple et que dans une compilation bibliothèque ou dll qui peut être référencé de l'application héritée.

C'est ... pas nécessairement une bonne idée. C # code peut exposer les interfaces COM qui sont accessibles en C ++. L'écriture de code client en C ++ pour les modules écrits en C # peut être amusant, mais vous pouvez le trouver taxer (en termes d'effort ratio avantages); Il est également lent et sujette aux erreurs (par rapport à l'écriture de code client C # pour les modules écrits en C ++).

Mieux envisager la création d'un cadre d'application en C # et en utilisant des modules (déjà) écrit en C ++ pour la fonctionnalité de base.

Est-ce possible et quel est le meilleur façon de le faire?

Oui, il est possible.

Combien de personnes sont impliquées dans le projet?

S'il y a beaucoup, la meilleure façon serait d'avoir quelques (deux? Quatre?) Le travail sur le nouveau cadre d'application et ont le reste continue comme d'habitude.

S'il y a peu, vous pouvez envisager d'avoir soit une personne responsable de cela, les gens ou plus de travail à temps partiel sur elle.

Le pourcentage de personnes / effort attribué à chaque (ancienne maintenance du code et le développement de code) devrait dépendre de la taille de l'équipe et vos priorités (La transition d'une question de faible priorité? Faut-il être terminé par une donnée jour?)

La meilleure façon de le faire serait de commencer à adapter les modules du code pour être utilisable dans plusieurs scénarios (à la fois l'ancien code et le nouveau) et poursuivre le développement en parallèle (encore une fois, ce serait grandement facilitée par l'utilisation une ramification système de contrôle de version distribuée).

Voici comment j'aller à ce sujet (développement itératif, avec de petites étapes et beaucoup de contrôles de validité entre les deux):

1. Choisissez un module fonctionnel (ce qui ne concerne pas l'interface graphique) dans l'ancienne base de code.

2. Supprimer le code MFC (et d'autres bibliothèques non disponibles dans VS2010 Express - comme ATL). Références à partir du module sélectionné à l'étape 1

   Ne pas essayer de réécrire la fonctionnalité MFC / ATL avec un code personnalisé, à moins que pour les petits changements (qui est, il est impossible de décider de créer votre propre cadre de GUI, mais il est OK pour décider d'écrire votre propre pointeur d'interface COM emballage similaire à CComPtr ATL).

   Si le code est fortement dépendante d'une bibliothèque, mieux séparer autant que possible, puis marquez-le à être réécrite à un point d'avenir en utilisant les nouvelles technologies. De toute façon, pour une bibliothèque fortement dépendante de MFC vous êtes mieux réécrire le code en utilisant autre chose (C #?).

3. réduire le couplage avec le module choisi, autant que possible (assurez-vous que le code est dans une bibliothèque séparée, décider clairement ce que la fonctionnalité Les expose module à code client) et l'accès la seule fonctionnalité délimitée par l'interface décidé exposée ( dans l'ancien code).

4. Assurez-vous que l'ancienne base de code fonctionne toujours avec le module modifié ( Test - éventuellement automatiser le test de ce module ) - ce qui est essentiel si vous avez besoin à toujours rester sur le marché jusqu'à ce que vous pouvez expédier la nouvelle version.

5. Tout en maintenant l'application en cours, démarrer un nouveau projet (C # basé?) Que implNTS l'interface graphique et d'autres pièces dont vous avez besoin de moderniser (comme les parties dépendantes fortement sur MFC). Cela devrait être une application en couche mince, de préférence agnostique de la logique métier (qui devrait rester dans le code existant autant que possible).

   En fonction de ce que l'ancien code fait et les interfaces que vous définissez, il peut être judicieux d'utiliser C ++ / CLI au lieu de C # pour certaines parties du code (il peut fonctionner avec des pointeurs C ++ natif et code managé, vous permettant de faire un transition facile quand comunicating entre le code managé .NET et du code natif C de).

6. Faire la nouvelle utilisation de l'application du module choisi à l'étape 1.

7. Choisissez un nouveau module, revenez à l'étape 2.

Avantages:

• refactorisation sera effectuée (nécessaire pour la séparation des modules)

• à la fin, vous devriez avoir une batterie de tests pour vos modules fonctionnels (si vous ne le faites pas déjà).

• vous avez encore quelque chose à navire entre les deux.

Quelques notes:

• Si vous n'utilisez un système de contrôle de version distribuée de branchement, vous êtes mieux de travailler sur un module à la fois. Si vous utilisez branchement / contrôle distribué source, vous pouvez distribuer différents modules à différents membres de l'équipe, et centraliser les changements chaque fois que quelque chose de nouveau a été porté.

• Il est très important que chaque étape est clairement délimité (de sorte que vous pouvez restaurer vos modifications à la dernière version stable, essayer de nouvelles choses et ainsi de suite). Ceci est une autre question qui est difficile avec SVN et facile avec Mercurial / Git.

• Avant de commencer, changer les noms de tous vos fichiers de projet pour avoir une extension .2005.vcproj, et faire la même chose pour le fichier de solution. Lors de la création du nouveau fichier de projet, faire la même chose avec .2010.vcxproj pour les fichiers de projet et solution (vous devriez toujours faire si vous convertissez les solutions / projets). L'idée est que vous devez ont tous les deux en parallèle et ouvert selon ce que vous voulez à tout moment. Vous ne devriez pas avoir à faire une mise à jour source arbre à un autre étiquette / tag / date dans le contrôle source juste dIDE commutateur.

Edit2: Nous avons regardé par écrit composants COM-emballés en C # mais ayant aucune expérience de ce COM est effrayant et compliqué.

Vous pouvez toujours le faire, en écrivant du code d'emballage (une petite classe de pointeur intelligent pour les interfaces basé sur un modèle COM ne dépareraient pas par exemple - similaire à CComPtr dans ATL). Si vous isolé le code COM derrière certains emballages, vous pouvez écrire du code client (agnostique COM) avec (presque) pas de problème.

Est-il possible de générer un dll C # avec une interface droite C avec toutes la bonté gérée cachée à l'intérieur? Ou est COM un mal nécessaire?

Pas que je sache. Je pense que COM sera un mal nécessaire si vous prévoyez d'utiliser le code de serveur écrit en C # et code client en C ++.

Il est possible que l'inverse.

Answer 3

D'abord, votre définition de l'ère moderne est sujette à controverse. Il n'y a aucune raison de supposer C # est mieux dans un sens que C ++. Beaucoup a été dit si C # vous aide à mieux les erreurs de gestion de la mémoire à éviter, mais ce ne l'est guère avec des équipements modernes en C ++, et il est très facile de le faire jouer avec C # en termes de calendrier d'acquisition des ressources, qui peuvent dépendre de ce que d'autres programmes font.

Answer 4

Si vous passez directement 6-2010 vous pouvez vous retrouver avec un peu foiré paramètres du projet. Si ce n'est pas un projet assez important, et il est l'un des rares que vous devez convertir, cela devrait être bien. Il suffit d'ouvrir en 2010, et suivez l'assistant de conversion. Assurez-vous de sauvegarder votre premier projet, et vérifiez vos paramètres du projet lorsque vous avez terminé.

À mon avis que la meilleure façon est de le convertir étape par étape chaque itération de Visual Studio. Je devais moderniser 1400 projets 2003-2010, et la meilleure façon que j'ai trouvé à tout converti à 2005, puis à 2008, puis enfin à 2010. Cela a provoqué le moins de questions à se poser pour moi.

Si vous avez seulement 6 et le plus récent Visual Studio vous pouvez finir par avoir juste essayer et aller directement à la nouvelle aide de l'assistant. Attendez-vous à un nettoyage manuel avant tout construit correctement pour vous.

En outre, une fois de plus, d'abord sauvegarder! :)

Answer 5

de haut niveau C ++ code d'appel bas niveau du code C # ne ressemble pas à une bonne idée. Les zones où les langages .NET sont mieux, sont l'interface utilisateur, l'accès base de données, la mise en réseau, les fichiers XML de traitement. Des vêtements de bas niveau comme les calculs, l'accès au matériel, etc. est préférable de garder code natif C ++.

Le passage à .NET, dans la plupart des cas, il est préférable de réécrire complètement l'interface utilisateur, en utilisant les technologies WPF ou Windows Forms. Des vêtements de bas niveau reste natif, et les différentes technologies d'interopérabilité sont utilisées pour connecter C # et code natif: PInvoke, C ++ / CLI ou wrappers COM interopérabilité. Après un certain temps, vous pouvez décider de réécrire les composants natifs de bas niveau en C #, que si elle est vraiment nécessaire.

A propos de la compilation du code C ++ natif dans VS2010 - Je ne vois pas de problème. Il suffit de corriger toutes les erreurs de compilation - nouveaux compilateurs ont plus stricte vérification de type et les restrictions de syntaxe et trouver les bogues beaucoup plus au moment de la compilation.

Answer 6

Je ne sais pas pourquoi tant de gens plaident en faveur de COM. Si vous ne l'avez pas déjà eu beaucoup de COM là, apprendre à le faire sur le côté C ++ va mal, et que vous utilisez le plus lent possible Interop du côté géré. Pas mon premier choix.

Idéalement, vous avez refondus votre interface utilisateur de votre logique métier. Vous pouvez ensuite créer une nouvelle interface utilisateur (WPF, WinForms, ASP.NET, services Web qui prennent en charge un autre client, peu importe) et un appel dans votre logique métier par P / Invoke ou en écrivant un C ++ / CLI wrapper. @mdma a de bons conseils pour vous présumez que le refactoring est possible.

Cependant si vous me payez à venir et vous aider à ma première question serait pourquoi voulez-vous faire? Certains clients disent qu'ils ne veulent pas payer C ++ devs plus, ils veulent tout le code C ++ disparu. Ceci est un objectif effrayant parce que nous avons tous la haine de toucher le code qui fonctionne. Certains clients veulent exposer leur logique à ASP.NET ou Reporting Services ou quelque chose, donc pour eux, nous nous concentrons sur le refactoring. Et certains disent « il a l'air si 1999 » et pour eux je leur montre ce que MFC ressemble maintenant. Couleurs, skinning / thématisation y compris bureau et regarde win7, ruban, vitres flottantes / docking et fenêtres, Windows 7 l'intégration barre des tâches ... si vous voulez juste regarder différent, jetez un oeil à MFC dans VS 2010 et vous pourriez ne pas avoir à régler tout code du tout.

Enfin, pour faire des versions non-Express de VS 2010 regard abordable dans le Microsoft Partner Program. Si vous avez vendu votre logiciel au moins 3 clients qui parlent encore à vous, et peut passer à travers l'auto-test du logo Windows 7 (j'ai VB 6 applications par le biais que dans un jour ou deux), alors vous pouvez avoir 5-10 copies de tout (Windows, office, VS) pour $ 1900 ou si une année, selon l'endroit où vous vivez.

Answer 7

Pour commencer, je vais essayer et garder code autant que possible pour éviter une ré-écriture. Je supprime aussi tout le code utilisé avant de commencer la conversion.

Depuis VC ++ 6.0 Microsoft a changé les bibliothèques MFC et la bibliothèque standard C ++.

Je recommande de commencer à construire votre DLL sans dépendances, à la recherche puis à vos bibliothèques de tiers, puis reconstruire une DLL / EXE à temps dépendant.

Introduire des tests unitaires pour vérifier que le comportement du code ne change pas.

Si vous avez une construction mixte, en utilisant différentes versions de VC ++, vous devez prémunir contre les ressources en passant (poignées de fichiers) entre DLL qui utilisent différentes versions du moteur d'exécution VC.

Answer 8

Dans la mesure du possible financièrement, je voudrais envisager simplement de payer l'argent pour la version de Visual Studio que vous avez besoin parce que vous pourriez très bien perdre plus d'argent sur le temps que vous passez. Je ne sais pas assez sur les éditions express pour donner une bonne réponse sur eux, mais lors de l'intégration du code d'un sous-traitant qui a été écrit en C ++ j'ai utilisé C ++ / CLI. Vous serez probablement en mesure de réutiliser la plupart de votre base de code et vous familiariser avec la langue, mais vous aurez également accès à code managé et bibliothèques. Aussi, si vous voulez commencer à écrire un nouveau code en C #, vous pouvez le faire. Le plus gros problème que j'avais avec elle était que dans VS 2010 il n'y a pas IntelliSense en C ++ / CLI.

Answer 9

Visual Studio 6 est légendaire pour être buggy et lent. Se déplacer dans l'ère moderne serait le mieux se faire en obtenant un nouveau compilateur. Ce qui est probablement la meilleure chose à faire est d'écrire l'application héritée dans une DLL, puis rédigez votre exe en C # et l'utilisation P / Invoke. Ensuite, vous ne devez jamais toucher l'ancien code again- vous pouvez simplement écrire de plus en plus en C # et l'utilisation de moins en moins de l'ancienne DLL.

Si votre ancien code est très fortement OO, vous pouvez utiliser C ++ / CLI pour écrire wrapper classes qui permettent aux méthodes d'appel .NET sur les objets C ++, et les recueillent aussi si vous utilisez une référence compté pointeur intelligent.

Answer 10

Vous pouvez utiliser C # pour écrire vos nouveaux composants avec une enveloppe COM ou COM + (System.EnterpriseServices), qui sera appelable à partir de votre code C ++ existant.