Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Comment passer en douceur de D5 à XE2?
J'ai une grosse application en Delphi 5 et je souhaite étudier son passage en Delphi XE2 et surtout trouver la manière la moins brutale.
Pour cela je me dis que je peux faire migrer petit à petit chacun de mes modules vers XE2 en transformant l'ancien .exe en .dll et en l'appelant depuis le nouvel .exe dans XE2.
Quel est votre avis et votre expérience à ce sujet?
Est-il possible de débugger depuis XE2 la dll delphi 5? je crois pas mais je pose quand même.
Que la source soit avec moi!
Jérôme JEAN-MARAULT
le plus doux (sauf pour le portefeuille) c'est de faire appel à mes services ^^
pour ce qui est des DLL, ça n'est possible que si les différents modules ne partagent pas d'objets...
la principale difficulté est le passage de string en WideString avec un choix sur le moment où il convient de passer de l'AnsiString à la WideString.
Si tu as la possibilité de modulariser en D5 avant la migration, cela peut être une bonne idée, dans mon ancienne boite, j'avais eu la même, j'ai changé de boite entre temps, et ils sont restés en D7
Depuis, j'ai expérimenté la migration BCB2007 à XE2, à par les codes utilisant manuellement du char* qu'il a fallu traquer, on a triché un peu, on a forcé le mappage en char et non en wchar_t
En Delphi, le mappage Unicode est obligatoire, donc String, PChar ... sont mappé en UnicodeString, PWideChar...
ça passe sans douleur sauf si tu as joué avec GetMem sur des PChar
Idem, si tu as utilisé manuellement des API Windows en version ANSI, il faut vérifier les Appels
Après tout dépend des Libs Externes, ça il faut reprendre les nouvelles versions (ça peu avoir un coup si payante) et d'autres devront être remplacées car ne sont plus maintenues !
Attention, pas de partage d'objet ou de string, il faut rester avec du PAnsiChar (partout évite le simple PChar), tu dois pouvoir utiliser ShortString, tu peux aussi échanger des record (de préférence packed)
Pour les BPL, évidemment, il y aura ceux pour D5 et ceux pour DXE2
Pour le débogage entre les versions, euh, les informations de débogage étant différentes, ça me semble très peu probable !
Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
Attention Troll Méchant !
"Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
L'ignorance n'excuse pas la médiocrité !
L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
Il faut avoir le courage de se tromper et d'apprendre de ses erreurs
Bonjour,
Une migration Delphi v5 vers Delphi XE2 est possible. Les principales questions sont effectivement les chaînes de caractère et l'évolution des composants tiers qui ont pu être utilisés dans l'application. XE2 est un bon choix et posera certainement moins de problèmes que les versions précédentes Unicode. Ne pas oublier l'optique Firemonkey dans la migration.
PS. Voir VIADEO
Je ne suis pas sûr que basculer tes modules en DLL soit une bonne idée. EN effet ça paraît sympa comme principe mais tu rajoute une couche (l'interface DLL) donc des bugs (si si !) et en plus un projet avec DLL est moins simple à débugguer.
Sinon comment faire ?
Bon déjà si tu as XE2 tu as aussi avec les anciennes versions de Delphi. Tu peux donc dans un premier temps migrer en Delphi7 (par exemple) ce qui doit être facile, en vérifiant/corrigeant les différents warnings de compilation. Quand tout est OK tu passe tout en XE2.
non le vrai défi c'est le passage en UNICODE (Delphi 2009), ce qui peut amener à modifier profondément certaines parties du code...le passage par D7 n'apportera rien dans ce contexte.Envoyé par philnext
Le Passage à l'UNICODE n'est même pas si dur, si l'on a pas joué avec les PChar, c'est à peine si l'on se rend compte du changement !
korntex5, Avant de modulariser, il faut prendre en compte le nombre d'élément, en particulier des librairies externes (où que le sont devenus) qui sont pénible à migrer, si le nombre est faible ou très bien maintenu, ça se passera sans encombre !
Faut juster se lancer !
Avec des directives de compilation, il est possible de conserver un code compatible avec D5
Lors du Passage BCB 2007 à XE2, c'est ce que mon équipe a fait !
En C++Builder, la migration est différente, d'autres facilités mais d'autres défaut aussi !
D’ailleurs, korntex5 n'est pas revenu nous lire, attendons ses précisions, si il n'utilise aucune lib externe (hors QRep), la modularisation est effectivement une perte de temps !
C'est vrai, une indirection introduit de nouveaux bugs !
Passez à D7 ou D2007 (Dernière ANSI) ne serait qu'une perte de Temps et d'Argent, il faudrait acheter\convertir les librairies externes de D7\D2007 puis en XE2, autant faire le saut d'un coup\coût !
Tout dépend, pensons par exemple à QuickReport, il n'existe plus en XE2, il faut donc racheter la nouvelle en plus de XE2 et donc le comportement peu être différent !
il peut être intéressant de "modulariser" cela pour reporter la migration ultérieurement !
C'est valable pour toute librairie qui n'est plus maintenue, on externalise le temps de trouver une solution de remplacement !
Cette modularisation peut amener à une réflexion d'architecture et pourquoi pas à des mécanismes comme DataSnap et des WebServices pour offrir un Client Web via RAD Php utilisant les mêmes fonctions métiers que le Client Lourd !
La Migration est le bon moment pour se poser des questions !
Perso, je maintiens une application de 40 exes et 80 DLL, sans aucune difficulté pour le débogage
En ce moment, je débogue une DLL chargé par une autre DLL et j'ai défini l'EXE comme Hôte de la 1ère DLL, je navigue entre les 3 modules sans soucis !
Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
Attention Troll Méchant !
"Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
L'ignorance n'excuse pas la médiocrité !
L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
Il faut avoir le courage de se tromper et d'apprendre de ses erreurs
outre les PChar et chaînes binaires, il faut porter une attention toute particulière aux entrées/sorties...un fichier, un socket, une API etc...dès qu'on communique avec l'extérieur du programme peut se poser le problème du format Wide ou Ansi des caractères.
Bon, ma réponse 'passer de D5 à une version la plus récente avant UNICODE' n'est valide que si il n'y a pas de bibliothèques tierces.
Dans ce cas je trouve que ça reste la solution la plus simple car ça sépare les problèmes...
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager