Est-il difficile de migrer un projet de Delphi 7 à Delphi XE ?

Question

Notre entreprise dispose d'un logiciel qui est en développement depuis plus de 10 ans, il y a donc des choses très anciennes. Il est encore assez fonctionnel et tout, mais je vois les nouvelles fonctionnalités de Delphi XE et cela me donne envie de changer. Le problème, c'est que le code source lui-même représente plus de 300 Mo de fichiers .pas (1 Go au total avec les composants, etc.).

Nous utilisons des composants personnalisés, des vieux trucs jvcl et le dernier devexpress.

À quel point les choses peuvent-elles être difficiles si je décide de migrer de Delphi 7 à Delphi XE ?

Merci.

Answer 1

Le seul véritable problème est la conversion en Unicode. Vous devriez apprendre comment le support Unicode est implémenté dans Delphi - commencez par Marco Cantu. Livre blanc : Delphi et Unicode

Il est impossible d'estimer la quantité de travail nécessaire pour mettre à niveau les anciennes applications vers Unicode sans connaître le code réel. Si vous utilisiez les types de chaînes de caractères de manière standard, la conversion serait facile. Toutes les astuces de bas niveau avec les types de chaînes (comme le stockage de données binaires dans des chaînes) sont maintenant dépréciées et le code correspondant doit être réécrit.

Answer 2

Certains petits outils migrent sans qu'il soit nécessaire d'apporter des modifications, ou bien il suffit d'apporter quelques corrections à l'unicode pour qu'ils fonctionnent.

Cependant, si votre base de code est aussi énorme que vous l'expliquez, vous ne devriez pas vous fier complètement à ce que quelqu'un ici va vous dire. Obtenez simplement une copie de XE et chargez le code. Voyez quels sont les problèmes que vous rencontrez pour avoir une idée de l'effort que cela va vous demander.

Pour l'instant, j'ai porté tout mon code vers XE (même les anciens projets). Je réutilise les mêmes bibliothèques autant que possible, donc une fois que j'ai converti la plupart d'entre elles, le "portage" des applications de Delphi 7 vers Delphi Unicode n'était généralement qu'une tâche répétitive pour traiter les interfaces mises à jour dans les bibliothèques, ou pour corriger les erreurs et les avertissements du compilateur.

Les erreurs les plus courantes que j'ai rencontrées :

• Des trucs Unicode. Cela prendra 90% du temps. C'est ennuyeux si le code fait beaucoup de manipulation de chaînes de caractères de bas niveau, mais la plupart des problèmes peuvent être facilement corrigés en ajoutant quelques typescasts.

• le compilateur râle quand on utilise c in ['a'..'z'] . Vous êtes censé utiliser CharInSet() pour les chaînes unicode.

• Si vous définissez ShortDateFormat, vous obtiendrez un avertissement du compilateur indiquant que vous devez utiliser FormatSettings.ShortDateFormat à la place. Dans un nouveau code, c'est une bonne idée. Dans le cas d'un portage, ignorez-le si vous souhaitez simplement vous lancer.

En outre, vous mettrez probablement à niveau vos bibliothèques tierces vers des versions plus récentes, afin de ne pas avoir à les porter vous-même. Il n'est pas rare que ces bibliothèques aient changé d'interface ou de fonctionnement. Je téléchargerais donc quelques versions d'essai de ces bibliothèques pour voir ce qui a été modifié.

Answer 3

Vous avez mentionné SQL dans l'un des commentaires de votre réponse... Votre base de données prend-elle en charge l'unicode ? Si ce n'est pas le cas, vous risquez d'avoir beaucoup de travail. Vous devrez peut-être convertir les bases de données à la volée ou créer un outil de conversion pour vos utilisateurs. Vous devrez peut-être mettre à niveau la base de données ou même passer à autre chose. Par exemple, DBISAM n'est pas compatible avec l'unicode, mais le fournisseur fabrique ElevateDB qui l'est. La transition n'est pas triviale. Et certaines autres bibliothèques comme Hyperstring, écrites en grande partie en assembleur, sont un autre point sensible.

Answer 4

J'ai fait tout à fait quelques-uns de ces conversions.

Vous devriez vous préparer en faisant votre base de code testable. De préférence à l'aide de tests unitaires automatisés, mais au moins un bon utilisateur final du plan de tests.

Ensuite, vous devez planifier pour la plus grande partie: la conversion Unicode pour votre application et votre base de données.

Enfin, il y a de moins en moins importants, mais potentiellement très coûteuse en temps les aspects:

• si vous utilisez le BDE, c'est le moment de se débarrasser de lui
• le Delphi XE est plus stricte que Delphi 7
• 3ème partie de la bibliothèque de versions qui bosse tout à fait un peu de versions et sont généralement beaucoup moins compatible que la VCL

Lorsque vous avez porté, il est temps de changer les choses: depuis que vous avez vu l'ensemble de la base de code, maintenant vous savez où sont vos points faibles sont, de sorte que vous pouvez commencer à refactoring et d'obtenir une meilleure application que vous aviez avant.

Answer 5

Mon projet compte environ un million de lignes de code et j'ai récemment effectué une migration de CB9 vers XE. Pour réduire la quantité de travail, j'ai d'abord réécrit une grande partie du code afin de ne plus dépendre de packs de composants tiers, puis j'ai revu avec soin tout ce qui concernait les chaînes de caractères (unicode), avant de passer à XE. La préparation a demandé beaucoup de travail, le portage proprement dit a été relativement facile.