Migration d'une application Delphi 7 vers .NET

Question

Un conseil sur la migration d'une application métier Delphi 7 existante vers .NET 2.0 dans Visual Studio 2005?

Visual Studio 2005 a déjà été acheté, la société souhaite quitter les outils Borland / Codegear.

L'application est un exécutable serveur client unique, qui utilise un certain nombre de contrôles d'interface utilisateur tiers et Crystal Reports 10 pour la génération de rapports.

La logique métier est étendue sur les types Delphi de l'interface utilisateur ainsi que sur de nombreuses procédures stockées SQL Server 2000. Déplacer une grande partie de la logique de proc stockée dans les classes .NET est un autre objectif.

Pour réduire l'impact sur les clients, une approche pièce par pièce serait préférable, si possible, à une réécriture / conversion complète. Merci d'avance.

[Mise à jour] Quelqu'un at-il déjà eu une expérience, bonne, mauvaise ou laide, d’utiliser la VCL gérée pour ce type de scénario?

Answer 1

J'ai travaillé pour une entreprise qui migrait de Delphi vers WPF / .Net vers 2007. Nous avons essayé une approche pièce par pièce. C'était douloureux. Nous étions toujours en train de rencontrer des bugs subtils dans l'interopérabilité. Appeler de Delphi vers WPF ou Winforms et inversement est douloureux. Si les divers contrôles de l’interface utilisateur et les fenêtres de votre application s’appellent beaucoup, je pense que vous éprouverez des difficultés de croissance importantes.

Si vous pouvez vous permettre de faire la conversion en une fois, je le ferais. Sinon, séparez les parties de votre application qui sont autonomes ou qui ont le moins d’interactions avec le reste de l’application.

Je suggérerais également de sauter dans .Net 2008. Pourquoi choisissez-vous une technologie de presque 4 ans (VS 2005)? Je pense que c’est une très très mauvaise décision de choisir de passer à .Net 2.0 alors que .Net 3.5 est très stable. La seule raison valable que je présenterais à la direction pour .Net 2.0 serait de prendre en charge Windows 2000. Avez-vous toujours des clients sur Win2k? Aurez-vous toujours des clients sur Win2k au moment où votre conversion sera terminée? Avez-vous des clients que vous ne pouvez pas passer à XP ou Vista? .Net 3.0 et 3.5 ne sont pas pris en charge par Win2k. C’est le seul inconvénient auquel je puisse penser.

.Net 3.5 et C # 2008 offrent des avantages significatifs pour votre entreprise. Vous disposez d'un certain nombre de fonctionnalités linguistiques qui accélèreront le temps de développement par rapport à C # 2.0. Vous avez WPF, qui est largement supérieur à Winforms. Je dirais que vous pouvez développer les mêmes fenêtres grises que celles que vous obtiendriez dans Winforms avec WPF, les développer plus rapidement et, lorsque vous voulez vous réjouir, vous utiliserez une technologie qui peut facilement la fournir. Si vous apprenez une nouvelle plate-forme de fenêtrage pour cette conversion, pourquoi ne pas investir dans l'apprentissage de nouvelles choses?

Veuillez également me dire que vous n'avez pas acheté VS 2005. Vous pouvez acheter un > de MSDN Universal à peu près au même coût et vous permet d’obtenir tous les produits liés au développement que Microsoft fabrique. Achetez-le chez un tiers et vous obtiendrez un bon rabais.

Désolé si je suis sorti négatif. Cordialement, bonne chance pour la migration. J'ai juste des flashbacks quand je pense à devoir abandonner tous les goodies de .Net 3.5.

Answer 2

Cela me semble être une très mauvaise idée .

Existe-t-il un avantage technologique pour votre produit à figurer dans .NET ou s'agit-il principalement d'une décision politique de devenir un magasin Microsoft? Pour client-serveur, Delphi est difficile à battre. J'ai utilisé VS2005 / 8 et il est vraiment et sincèrement pas aussi bon que Delphi pour le développement Win32. Mais si vous envisagez de migrer sur le Web à terme, VS dispose d’avantages décisifs.

Si les gens d'affaires obstinés refusent tout simplement de ne plus utiliser Delphi, alors KiwiBastard est correct, IMO. Convertissez d'abord vers Delphi.NET, puis migrez-là vers VS2005. Ou 2010, car il s’agit d’un calendrier plus réaliste:)

Answer 3

Auparavant, je travaillais dans une entreprise qui souhaitait convertir Delphi en C # .NET car .NET était tout à la fois cool et brillant . Ils ont fait venir d’autres développeurs qui avaient beaucoup d’expérience C # et il a fallu 3 fois plus de temps aux développeurs pour porter l’application sur C #, puis l’écrire pour la première fois dans Delphi avec très peu de retour sur investissement supplémentaire (quelques-uns). de nouvelles fonctionnalités ont été ajoutées au cours du processus). De plus, les clients n'étaient pas satisfaits des performances de l'application ou de l'interface utilisateur.

L'étude de cas après étude de cas montre que la la réécriture est une mauvaise idée . (Astuce de chapeau pour kogus )

Si vous devez passer à .NET (oui, je sais, vous n'avez pas pris la décision, quelqu'un avec moins d'informations l'a fait), je vous suggère d'utiliser Delphi pour .NET ou RemObjects Oxygene . Ce dernier étant un plug-in Visual Studio. Mais même marc hofman, l'architecte en chef des logiciels de RemObjects Oxygene a déclaré que c'était une mauvaise idée de migrer une application fonctionnant parfaitement vers .NET "simplement parce que".

Si vous pouvez attendre Delphi Prism, qui est également un complément de Visual Studio et qui devrait sortir plus tard cette année.

Answer 4

Une conversion fragmentaire impliquerait de changer le code Delphi natif pour utiliser COM afin que le côté .NET puisse coexister avec Delphi (ou éventuellement utiliser une autre technologie difficile à dire)

Si vous le pouvez, il serait peut-être plus facile de convertir d'abord l'application en Delphi.NET, alors au moins les bits .NET pourront communiquer un peu plus facilement.

Juste une pensée.

Answer 5

S'éloigner des outils CodeGear / Borland élimine en principe toute solution basée sur Delphi .NET et une réécriture totale de votre application.

J'espère que ma réponse ci-dessous vous aidera dans vos décisions.

Par expérience (avoir réécrit une application Delphi avec une équipe de personnes), cela revient à choisir l’un des deux choix ci-dessous.

Mais tout d'abord un avertissement: vous devrez au moins déployer tout l'effort de développement nécessaire pour écrire votre application Delphi actuelle.

Dans notre cas, cet effort était justifié dans la mesure où l’ancienne application Delphi (qui était en fait Kylix) était en fin de vie pour diverses raisons. Notre réécriture se composait de deux parties: la réécriture avec une fonctionnalité supplémentaire limitée suivie de nombreuses fonctionnalités supplémentaires (la conception de la première partie tenait déjà compte de la seconde partie).

Retour à vos choix:

1- Une réécriture totale en C # ou VB.NET dans Visual Studio

2- une réutilisation partielle de votre code de couche de gestion Delphi existant en utilisant Oxygene de RemObjecs (un plugin Visual Studio avec une syntaxe très similaire à la syntaxe Delphi). CodeGear proposera bientôt Prism (probablement avant la fin de 2008), qui sera également intégré à Visual Studio.

Etant donné que l’accès aux données .NET et l’interface utilisateur sont totalement différents de Delphi, vous devrez les faire à partir de zéro (pour les scénarios 1 et 2). Visual Studio 2008 offre de nombreux avantages par rapport à Visual Studio 2005.

Il n’existe pas de migration progressive, car vous effectuez ici un changement complet de plate-forme. C’est une approche tout ou rien.

Les deux scénarios prendront beaucoup de temps (même si vous avez une expérience de Delphi, il vous faudra du temps pour vous habituer au monde .NET).

Visual Studio peut interagir avec Crystal Reports et fonctionne bien avec SQL Server.

Etant donné que Visual Studio 2008 offre de nombreux avantages (non seulement .NET 3.5, mais également en termes de productivité), vous feriez bien de choisir. En ce qui concerne l'interface utilisateur, vous devez faire un choix équilibré entre WinForms (Windows Forms) et Windows Presentation Foundation (WPF).

S'il s'agit d'une réécriture personnalisée, vous pouvez vous en tenir à WinForms, car il est familier avec ce que vous avez. Vous devrez probablement utiliser des composants tiers pour obtenir votre interface utilisateur; DevExpress est un bon choix ici car ils ont des composants similaires dans Delphi et Visual Studio.

Mais si vous voulez opter pour le plaisir des yeux, vous pourriez envisager WPF. Préparez-vous à une courbe d'apprentissage plus abrupte que WinForms, car elle est très différente de ce que vous avez l'habitude de vivre.

Si vous décidez de rester avec Delphi, vous voudrez peut-être vous intéresser à la VCL pour le Web (aussi appelée IntraWeb) et à Delphi 2009 (beaucoup de choses ont changé dans le monde de Delphi depuis l'annonce de Delphi 7 il y a 6 ans).

Bonne chance dans vos choix!

- jeroen

Answer 6

Je suggérerais de regarder Hydra de RemObjects. Fondamentalement, il rap l'interface pour vous et fournit un modèle d'observateur pour l'interface entre votre application Delphi et .Net. Vous pouvez afficher des formulaires .Net dans des panneaux de votre application Delphi. Cela fournit un chemin de migration intéressant dans lequel vous remplacez votre code Delphi au fur et à mesure de la migration de la fonctionnalité vers .Net.

Answer 7

Pour moi, la question serait: quelle langue utiliseriez-vous? J'espère que C # et pas VB.Net. (Avec toute la politique délicate de cette affaire, cela n’est pas clair.)

Vous allez probablement entendre qu'il y a des convertisseurs qui vous aideront à le faire. Nous venons de passer en revue une évaluation de tels convertisseurs (Delphi 7 en C #) et avons été très! déçu.

Puis-je suggérer un compromis? Que diriez-vous de Delphi Prism? C'est Delphi dans VS2008. Bien sûr, vous avez toujours Delphi et donc Codegear, mais vous avez aussi le statut de VS (comme votre entreprise l’attend).

Answer 8

Il y a eu un rapport scientifique sur la transformation réussie d'un projet Delphi de 1,5 million de lignes en C # par John Brant, Don Roberts et al. Il a écrit un analyseur Delphi, un générateur C # et de nombreuses règles de transformation sur l'AST. L'extension progressive de l'ensemble de règles, la construction quotidienne, de nombreux tests unitaires et la réécriture de parties difficiles de Delphi lui ont permis de former une équipe de 4 personnes, parmi lesquelles des développeurs originaux, avec des outils Delphi profonds. Connaissance C #, pour migrer le logiciel en 18 mois. John Brant & amp; Don Roberts étant les développeurs originaux du navigateur de refactoring et du kit de construction du compilateur SmaCC, il est peu probable que vous puissiez aller aussi vite.

Bien qu’il s’agisse d’un investissement important, il n’est nulle part "de la même taille que le développement initial". Les auteurs notent qu'une très simple réécriture, sans outil ou avec un seul outil, comme l'a noté Jeroen, va très probablement entraîner cela, en particulier si de nouvelles exigences sont prises en compte.

Les auteurs ont procédé à une refactorisation à grande échelle tout en restant sur la même plate-forme pour un projet différent, remplaçant ainsi complètement l'infrastructure de persistance. Cela pourrait être pertinent pour les projets plus anciens (BDE?).

Answer 9

Vous seul pouvez vraiment décider si une approche pièce par pièce est possible. Par exemple, l’application peut-elle être facilement divisée ou toutes les formes sont-elles trop fortement associées à toute la logique métier? Techniquement, c'est possible, mais tout dépend de la structure de la base de code.