Est-ce difficile de faire passer un projet de Delphi 7 à Delphi XE?
notre société a un logiciel qui est en développement depuis plus de 10 ans, donc il y a des trucs vraiment datés là-dedans. Il est encore assez fonctionnel et tout, mais je vois les nouvelles fonctionnalités sur Delphi XE et il me donne envie de passer. Le problème est que le code source lui-même est supérieur à 300 Mo .Fichiers pas (1 Go au total avec les composants, etc).
nous utilisons des composants personnalisés,de vieux trucs jvcl et le dernier devexpress.
à quel point puis-je m'attendre à ce que les choses soient difficiles si je décider de migrer de Delphi 7 à Delphi XE?
je vous Remercie.
6 réponses
le seul vrai problème est la conversion en Unicode. Vous devriez apprendre comment le support Unicode est implémenté dans Delphi-commencer à partir de Marco Cantu Livre blanc: Delphi et Unicode
il est impossible d'estimer la quantité de travail nécessaire pour mettre à niveau D'anciennes applications vers Unicode sans connaître le code réel. Si vous utilisiez les types de chaîne de caractères de la manière standard, la conversion serait facile. Tous les trucs de bas niveau avec des types de chaîne (comme stocker des données binaires dans des chaînes de caractères) sont maintenant obsolètes et le code correspondant devrait être réécrit.
certains petits outils migrent sans avoir besoin de faire des modifications, ou juste quelques corrections unicode pour le faire fonctionner.
cependant, si votre code est aussi énorme que vous l'expliquez, vous ne devriez pas complètement compter sur ce que quelqu'un ici va vous dire. Il suffit d'obtenir une copie de XE et de charger le code. Voyez quels problèmes vous rencontrez pour avoir une idée de la quantité d'effort que cela va prendre.
en ce moment j'ai porté tout mon code sur XE (même les vieux 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 Delphi 7 vers Unicode Delphi était généralement une tâche répétitive, soit pour traiter des interfaces mises à jour dans les bibliothèques, soit pour corriger les erreurs et les avertissements du compilateur.
erreurs les plus courantes que j'ai rencontrées:
Unicode choses. Cela va prendre 90% du temps. C'est ennuyeux si le code fait beaucoup de manipulation de string de bas niveau, mais la plupart des les problèmes peuvent facilement être résolus en ajoutant quelques typographies.
le compilateur chiennes lorsque vous utilisez
c in ['a'..'z']. Vous êtes censé utiliserCharInSet()pour les chaînes unicode.si vous définissez ShortDateFormat, vous obtiendrez un avertissement de compilateur que vous devriez utiliser FormatSettings.ShortDateFormat à la place. Dans le nouveau code, c'est une bonne idée. Si vous transférez, ignorez-le d'abord si vous voulez juste y aller.
en Outre, vous mettrez probablement à jour vos bibliothèques tierces vers des versions plus récentes, de sorte que vous n'ayez pas à les porter vous-même. Il n'est pas rare que ceux-ci aient changé leurs interfaces ou leur fonctionnement, donc je téléchargerais quelques versions d'essai de ceux-ci pour voir ce qui a été changé.
vous avez mentionné SQL dans l'un de vos commentaires en réponse... Votre base de données supporte-t-elle unicode? Si non, vous pourriez être dans un beaucoup de travail. Vous pouvez avoir besoin de convertir des bases de données à la volée ou de faire un outil de conversion pour vos utilisateurs. Vous pouvez avoir besoin de mettre à jour la base de données ou même passer à autre chose. Par exemple, DBISAM n'est pas capable unicode, mais le vendeur fait ElevateDB qui est. La transition n'est pas trivial. Et quelques autres bibliothèques comme Hyperstring, écrit en grande partie en assembleur, sont un autre point sensible.
j'ai fait pas mal de conversions.
vous devez vous préparer en rendant votre code de base actuel testable. Utiliser de préférence des tests unitaires automatisés, mais avoir au moins un bon plan d'essai de l'utilisateur final.
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 des aspects moins importants, mais qui peuvent prendre beaucoup de temps:
- si vous utilisez le BDE, c'est le le temps de se débarrasser de lui
- le Delphi XE est plus strict que le Delphi 7
- versions de bibliothèque de tierce partie qui se bousculent pas mal de versions et sont généralement beaucoup moins compatibles vers l'arrière que la VCL est
quand vous l'avez porté, il est temps de changer les choses: depuis que vous avez vu toute la base de code, Maintenant vous savez où sont vos points faibles, donc vous pouvez commencer à les refactoriser et obtenir une meilleure application que vous aviez auparavant.
mon projet est d'environ un million de lignes de code et j'ai récemment porté de CB9 à XE. Pour réduire la quantité de travail j'ai tout d'abord réécrit beaucoup de sorte que je n'étais plus dépendant des paquets de composants de tierce partie, puis soigneusement passé en revue tout ce qui est lié à la chaîne de caractères (unicode) et seulement ensuite déménagé à XE. La préparation a été beaucoup de travail, le port a été relativement facile.
c'est certainement un défi pour cette MIGRATION d'être exécutée. Mais il faut une bonne planification!
nous devons d'abord trouver tous les composants possibles qui doivent aussi être migrés avec le Code. S'il y a des composants tiers utilisés dans le projet Delphi7 qui ne sont pas disponibles, alors c'est assez compliqué d'aller plus loin. Deuxièmement, l'autre conversion de type lié à Unicode, qui est assez facile. Et enfin, bien sûr, nous devons obtenir d'autres bibliothèques de soutien, BDE, et Adaptateurs de base de données en place.
Pour L'Interface Utilisateur Riche, Delphi FireMonkey peut être utilisé.
Delphi est de mieux en mieux car il a maintenant le soutien de L'ordinateur de bureau au Web au développement D'applications Mobiles.