Comment migrer une grande application de Visual Basic 6.0 à VB.NET ?

Question

Ma société fabrique un logiciel monolithique que nos clients utilisent pour gérer leurs concessions automobiles. L'application d'origine a été écrite en Visual Basic 6.0, et elle s'est considérablement développée au cours des dernières années. Jusqu'à présent, il n'y avait pas vraiment d'intérêt commercial à passer au framework .NET. Bien sûr, il est plus récent, considérablement meilleur pour certaines choses et, lorsqu'il est utilisé correctement, il accélère le temps de développement, mais il n'y a rien que nous ne puissions faire dans Visual Basic 6.0 et que nous devions être en mesure de faire. Faire les choses est plus difficile en Visual Basic 6.0, mais presque rien n'est impossible. Récemment, Microsoft a abandonné la prise en charge de Visual Basic 6.0, et il me semble évident que le passage à une nouvelle plate-forme est inévitable.

Le mode de fonctionnement de VB.NET et la façon dont vous devez penser sont fondamentalement différents (même la façon dont vous passez les variables dans les sous-programmes a changé) et, pour autant que je sache, le passage à .NET nécessiterait une reconception et une réécriture complètes de l'application.

Ma (mes) question(s) : L'un d'entre vous s'est-il trouvé dans cette situation ? Parmi les outils disponibles pour faciliter la transition, lesquels fonctionnent et lesquels sont à éviter ? Et comment convaincre nos clients et mon patron ? Comme les hommes d'affaires aiment à le dire, où se trouve la ROI ?

---

@Rob Burke :
Un tas de WinForms : Absolument.
Code ADO pour l'accès à la base de données : Oui, mais tout cela en un seul endroit facile à gérer.
Pages web ASP : Aucune. Il s'agit strictement d'une application de bureau.
Contrôles personnalisés : Oui, mais elles sont toutes écrites par nous (c'est-à-dire qu'elles n'appartiennent pas à des tiers).
Base installée : ~1000 machines.

La dernière fois que j'ai appelé le service d'assistance technique de Microsoft (j'avais 16 ou 17 ans à l'époque), j'avais des difficultés à faire fonctionner la bibliothèque MSDN sur mon ordinateur (à l'époque où MSDN n'était pas disponible en ligne et où les connexions Internet étaient commutées). Après avoir élevé mon dossier d'assistance, la "solution" qu'ils m'ont donnée était de formater mon disque dur et de tout réinstaller. Inutile de dire que je n'ai pas considéré cela comme une solution.

Answer 1

Le livre sur la mise à niveau de VB6 vers VB.NET recommandé par Jonathan est utile, mais vous n'avez pas besoin de ont a acheter il - il est disponible en tant que téléchargement gratuit à partir du site web de Microsoft.

Mon conseil est de ne pas sous-estimer l'effort de conversion - soyez très prudent avant de vous lancer dans une réécriture. C'est un piège fréquent de commencer avec optimisme, de faire des progrès rapides en corrigeant certains des défauts bien connus de l'ancienne architecture, puis de s'enliser dans les fonctionnalités que vous avez considérées comme acquises pendant des années. À ce stade, votre direction commence à s'agiter et tout peut devenir très inconfortable.

...et voici un billet de blog d'un Microsofty qui est d'accord avec moi :

De nombreuses entreprises avec lesquelles j'ai travaillé aux premiers jours de .NET ont d'abord envisagé la réécriture, en partie motivées par un fort désir d'améliorer l'architecture sous-jacente et les structures de code en même temps qu'elles passaient à .NET. Malheureusement, nombre de ces projets se sont heurtés à des difficultés et plusieurs n'ont jamais été menés à terme. Le problème qu'ils essayaient de résoudre était trop important.

EDIT : (ajouté cette citation d'un nouvel excellent Microsoft page web ).

Une réécriture complète en .NET est beaucoup plus coûteuse et difficile à réaliser correctement [que la conversion]... nous ne recommandons cette approche que dans un petit nombre de cas.

Ainsi que le célèbre expert VB Dan Appleman dit :

Dans la plupart des cas, le portage [de VB6 à VB.NET] est stupide et constitue un véritable gaspillage d'argent. gaspillage d'argent.

Et Joel a déclaré il y a quelque temps :

La pire erreur stratégique qu'une entreprise de logiciel puisse faire [est de] décider de réécrire le code à partir de zéro.

Quelques autres liens utiles sur la migration, y compris des liens vers un autre livre gratuit de Microsoft. Un . Deux . EDIT : Nouveau Microsoft page y compris screencast avec leur réponse à cette question.

Et enfin, Microsoft a no a en fait totalement abandonné la prise en charge de Visual Basic 6. Le site Le runtime est pris en charge sur Windows Vista, Windows 7, 8 et Server 2008 pendant toute la durée de vie de ces systèmes d'exploitation. Voir le Déclaration officielle de Microsoft .

Answer 2

Je suis d'accord avec Eric lorsqu'il dit que vous devez traiter Visual Basic 6.0 et VB.NET comme des plateformes complètement différentes. Vous n'aurez aucun moyen facile de porter votre logique d'une manière qui vous fera gagner du temps et qui ne vous enchaînera pas aux déficiences de Visual Basic 6.0.

En termes de retour sur investissement : faites une liste de toutes les tâches de support que vous avez effectuées au cours de l'année écoulée, et estimez le gain de temps qu'elles auraient représenté si vous aviez travaillé avec une application VB.NET bien structurée plutôt qu'avec votre vieux dinosaure Visual Basic 6.0. Il s'agit de vos économies annuelles en matière de support. Si vous avez des mises à niveau importantes à venir, tenez-en compte également. Y a-t-il des propositions de nouvelles fonctionnalités ou de mises à niveau qui ont été rejetées parce qu'elles étaient trop difficiles en Visual Basic 6.0, mais qui seraient réalisables en VB.NET ? S'il y a de grandes fonctionnalités à venir ou que vous aimeriez inclure, alors vous pourriez voir un bon retour sur investissement pour passer à VB.NET. Si le programme est fondamentalement stagnant et qu'il n'y a aucun plan pour changer le statu quo, alors vous n'obtiendrez probablement pas l'adhésion dont vous avez besoin.

Answer 3

Tout d'abord, je dois dire que je travaille pour ArtinSoft, donc mon opinion ici est basée sur ce que j'ai vu chez nos clients. Cependant, mes expériences de développement de logiciels avant ArtinSoft remontent à plus d'une décennie et sont tout à fait pertinentes pour le sujet qui nous occupe.

Ai-je été dans cette position ?

Oui, absolument et en de nombreuses occasions. Il est très rare que j'aie vu une entreprise aborder cet obstacle de manière proactive. Le plus souvent, j'ai vu des entreprises et leurs applications logicielles dépérir avec des technologies non prises en charge qui ont attendu trop tard, jusqu'à ce que les sables rapides de l'obsolescence technique ne leur laissent que peu ou pas de choix. Et dans plus d'un cas, certaines se sont même retrouvées dans une situation où seule une réécriture complète pouvait les sauver. Ce n'est pas l'endroit où vous voulez être.

Comment le vendre à vos clients ?

Je serais honnête avec vos clients... vous voulez continuer à offrir un produit supérieur et être capable de répondre rapidement à leurs besoins au fur et à mesure que le produit évolue. L'environnement actuel de Visual Basic 6.0 rend cela de plus en plus difficile. Il est de plus en plus difficile de trouver des développeurs Visual Basic 6.0 talentueux ou des développeurs .NET talentueux qui tolèrent Visual Basic 6.0. Et même si vous y parvenez, ce talent va devenir de plus en plus cher à mesure que la réserve de talents diminue et que la satisfaction professionnelle s'amenuise.

Vos clients utilisent d'autres applications dans le cours normal de leur vie, et ils finiront par remarquer que votre application vieillit, qu'elle est dépassée et qu'elle ne répond plus aux mêmes attentes que cette autre application au jour le jour.

Comment allez-vous vendre ça à votre patron ?

Comme je ne suis pas sûr de la situation exacte dans laquelle vous vous trouvez, voici les possibilités que j'ai le plus envisagées lorsque j'ai envisagé de faire de telles transitions dans le passé. Et vous voudrez peut-être trouver des leaders commerciaux et techniques au sein de votre entreprise pour vous aider à défendre cet effort et à déterminer la manière la plus appropriée de vendre ce produit dans votre organisation.

1. Avantages concurrentiels / perception du client

Je suppose que votre application n'est pas la seule dans l'univers des logiciels pour concessionnaires automobiles. Si la vôtre est la première à faire le grand saut vers .NET, c'est formidable. Mais si c'est la dernière... est-ce vraiment là où votre entreprise veut être ? Est-ce quelque chose qui pourrait empêcher un client de renouveler son contrat de maintenance - en supposant que vous génériez des revenus de cette manière ? Si c'est le cas, quel meilleur moyen de prouver la valeur d'un contrat de maintenance que de mettre l'application à niveau ?

2. Réserve de talents et rétention

Je ne sais pas si vous avez déjà été confronté à ce phénomène ou comment votre personnel technique est structuré, mais les technologies plus anciennes deviennent de plus en plus coûteuses, produisent de moins en moins d'innovation et rendent de plus en plus difficile d'attirer et de retenir les talents, au point que le moral peut être sérieusement affecté. À l'heure actuelle, le talent .NET est très abordable et disponible. Il est toujours amusant, toujours à la mode et offre un potentiel de carrière long et précieux pour ceux qui travaillent avec lui.

3. Nouvelles fonctionnalités et composants tiers

Je suppose que vous continuez à déployer de nouvelles fonctionnalités ? Et je suppose que vous avez peut-être remarqué qu'il y a de moins en moins d'échantillons de code disponibles en ligne dans Visual Basic 6.0. Il y a moins de personnes qui répondent aux forums de Visual Basic 6.0... sauf bien sûr si c'est en relation avec .NET. Il y a moins de support pour les composants tiers de Visual Basic 6.0 et les projets open-source. Visual Studio pour .NET est une amélioration considérable par rapport aux versions de Visual Basic 6.0. Et le langage .NET et les bibliothèques natives peuvent rendre inutiles certains des composants tiers de votre application.

4. Correction de bogues et amélioration des performances

Les outils de profilage des performances dans .NET sont à couper le souffle par rapport à ce qui était disponible auparavant avec Visual Basic 6.0. Il est tout simplement plus facile de travailler avec du code géré. Le débogage dans Visual Studio pour .NET est incroyablement efficace. Et bien sûr, de nombreuses améliorations ont été apportées à la connectivité, au traitement des exceptions et à la gestion de la mémoire, pour n'en citer que quelques-unes.

5. Crée une nouvelle valeur.

Au bout du compte, pensez-vous que le fait d'avoir une application .NET plutôt qu'une application Visual Basic 6.0 augmentera la valeur de votre entreprise ? Qu'elle soit privée ou publique, peu importe - la valeur de votre application devient un actif important. S'ils sont comptabilisés correctement, tous les coûts de développement peuvent être amortis au fil du temps comme un investissement en capital. Je ne suis pas fiscaliste, mais je sais que cela peut vraiment changer l'équation.

6. Feuille de route

Le passage à .NET est un endroit fantastique où se trouver, car les étapes en direction de Silverlight et/ou le passage au Cloud sont tellement plus proches de la réalité que cela ouvre vraiment des possibilités. En fait, avez-vous envisagé une telle évolution ? Les cas d'affaires pour cela peuvent être époustouflants. Il s'agit d'un véritable changement de paradigme qui peut réduire considérablement les coûts et amener votre logiciel à des endroits dont vos concurrents ne peuvent que rêver. En tout cas... Je m'éloigne du sujet sans en savoir plus sur votre logiciel et votre modèle économique.

Parmi les outils disponibles pour faciliter la transition, quels sont ceux qui fonctionnent et ceux qu'il faut éviter ?

Sauf pour les petites applications, je déconseille fortement une réécriture. Bien sûr, qui n'aimerait pas avoir l'opportunité de refactorer. Mais l'objectif qui peut souvent se perdre dans une telle migration est juste cela... migrer. Le remaniement et les modifications de l'architecture peuvent toujours intervenir plus tard. Ces obstacles sont beaucoup plus petits et devraient vraiment être évités pour minimiser les risques.

Comme L'utilisateur RS Conley déclare dans une autre réponse S'il est essentiel de préserver le comportement de votre application ou s'il s'agit d'une mission critique, la conversion est la seule solution".

Un autre utilisateur, MarkJ, nous a fourni un lien vers un message d'Eric Nelson, de Microsoft, http://msdn.microsoft.com/en-gb/dd408373.aspx#migrate où il est dit que de nombreuses réécritures ont été abandonnées en raison de la complexité inattendue et écrasante. Nous avons entendu parler de nombreuses tentatives de réécriture qui ont échoué ; certains d'entre eux nous ont contactés en tant que clients après avoir décidé de procéder d'abord à une réécriture.

Voici un livre blanc rédigé par un de mes collègues sur ce sujet précis : http://www.artinsoft.com/5-myth-busting-reasons-for-choosing-automatic-migration-vs-manual-rewrite.aspx

N'essayez pas d'améliorer la fonctionnalité de l'application tant que le passage à .NET n'est pas terminé. Il est facile de laisser l'étendue du projet vous échapper. Il est tentant, alors que vous avez le patient sur la table, de faire d'autres soins préventifs en retard, mais résistez à la tentation. Une migration vers .NET n'est pas pour les âmes sensibles.

Vous devez rechercher un outil qui préservera votre logique d'entreprise. Il convertira autant de composants tiers en leur équivalent .NET que possible. En fonction des normes de codage en vigueur lorsque votre application a été écrite à l'origine et du respect de ces normes par la suite, il est préférable de trouver un outil qui maintiendra la structure des classes de votre application afin que vos développeurs actuels n'aient pas besoin de réapprendre à naviguer dans le code. Cela peut vous faire gagner beaucoup de temps pour revenir à vos activités. N'oubliez pas non plus que si l'application d'origine est mal écrite, le code qui résulte d'une migration automatique peut ne pas être une idée. Quelle est l'expression "garbage in, garbage out" ?

Dans tous les cas, faites-moi savoir si je peux vous être utile. J'espère que mes commentaires ont apporté un éclairage utile.

Bonne chance !

Answer 4

Je suis passé par ce processus il y a environ 18 mois. Nous avions beaucoup de code Visual Basic 6.0 qui devait être porté vers .NET.

Notre code était une collection d'EXE et de DLL dans plusieurs projets différents, ce qui m'a permis d'aborder chaque projet individuellement. J'ai utilisé l'outil de migration VB de Visual Studio pour effectuer une première conversion vers VB.NET. J'ai ensuite dû effectuer une lot de nettoyage pour que le logiciel se compile.

Petit à petit, chaque projet a été converti et nous avons pu dire adieu à Visual Basic 6.0.

Ce qui est génial, c'est que tout notre code s'exécute maintenant sur VB.NET, de sorte que le Visual Basic s'intègre très bien aux autres projets que nous avions écrits en C#. Nous avions beaucoup de fonctionnalités dupliquées en C# et Visual Basic 6.0, donc maintenant tout utilise le code C#.

Nous pouvons également utiliser Visual Studio 2008 qui est beaucoup, beaucoup plus agréable et plus productif que l'IDE Visual Basic 6.0. Il prend même en charge la molette de la souris.

Les inconvénients : L'utilisation de l'outil de migration signifie que nous avons du code .NET mais avec la structure d'un programme Visual Basic 6.0. Ce n'est pas du tout ce que vous écririez si vous partiez de zéro en VB.NET. Nous procédons progressivement au remaniement de la structure de Visual Basic 6.0.

Néanmoins, je pense que l'utilisation de l'outil de migration a été un processus plus rapide et plus fiable que la réécriture à partir de zéro.

C'était un processus qui demandait beaucoup de travail. Plusieurs mois de travail pour produire un logiciel qui ressemblait et se comportait exactement comme la version Visual Basic 6.0. Mais depuis lors, la mise à jour et la maintenance du code ont été un jeu d'enfant et valent bien l'investissement.

Answer 5

Étape 1 : Réécrire l'interface utilisateur en VB .net. C'est assez facile. Même un outil de conversion peut probablement le faire correctement.

Étape 2 : Reconstruire les composants VB6 en tant que DLL. C'est une nuisance modérée, puisque vous devez remplacer tous vos accès à l'interface utilisateur par des hooks qui peuvent être appelés. La difficulté de cette étape est proportionnelle au degré de couplage entre votre interface utilisateur et votre logique. En cas de difficulté, vous pouvez laisser l'interface utilisateur en place de manière invisible et faire en sorte que les hooks accèdent à l'interface utilisateur... mais il s'agit au mieux d'un hack.

Étape 3 : Attacher le front-end de l'interface utilisateur aux composants VB6. Cette étape est quelque peu ennuyeuse.

À ce stade, vous avez déjà une application .Net et vous pouvez réécrire à volonté tous les appels au code VB6. De même, les modifications apportées au code VB6 apparaîtront dans votre code .Net pendant la période où vous développez encore les deux.