2011-06-01 8 views
5

L'un de nos clients souhaite que son application Delphi soit convertie en .NET 4.0. Après avoir lu les réponses à diverses questions similaires sur ce site, j'ai décidé d'adopter une approche pas à pas pour convertir le code Delphi en .NET.Conversion de Delphi vers .NET 4 (sans outil)

Depuis que je suis un développeur .NET, je dois d'abord me familiariser avec Delphi. Il est assez difficile de trouver un seul site qui a fourni un aperçu complet des concepts de Delphi. Aussi, je n'ai pas encore trouvé de site qui fournit des informations sur les équivalents de Delphi dans .NET. Par exemple, quel est l'équivalent de "stdcall" ou "export" dans .NET? ou quel est l'équivalent d'un type de données Delphi particulier dans .NET?

Est-ce que quelqu'un connaît une telle ressource en ligne qui fournit des informations sur les équivalents Delphi dans .NET? Aussi, si quelqu'un pouvait fournir des conseils à ce sujet?

+0

c'est beaucoup trop large pour y répondre. Lisez le guide de la langue delphi et prenez-le à partir de là. –

+0

Voir le wiki de la documentation d'Embarcadero ici: http://docwiki.embarcadero.com/RADStudio/en/Main_Page –

+3

Je voudrais ajouter que la recherche d'une correspondance 1: 1 entre les éléments de langage est erronée.Si cela pouvait le couper, il y aurait des outils automatisés pour le travail. Par exemple, les mots clés 'stdcall' et' export' signalent une DLL conçue pour être utilisée à partir d'autres applications. Il n'y a pas d'équivalent direct dans le monde .NET car vous ne pouvez pas lier à une bibliothèque .NET à partir d'une application native, vous devez utiliser toutes sortes de technologies d'interopérabilité. –

Répondre

2

Vraiment, le meilleur moyen de le faire est de partir rayure. Essayer de convertir le code hérité de Deplhi en C# est juste chargé de problèmes, et à la fin de celui-ci, vous aurez une application C# de type Delphi. Les frameworks sous-jacents, VCL dans Delphi, et FCL dans .NET, ont des différences architecturales significatives, donc étant donné que le temps de conversion sera à peu près équivalent à la durée de développement à partir de zéro, vous vous condamnez à une 2ème classe application si vous descendez le chemin de conversion.

Et je pourrais ajouter que j'ai converti avec succès un cadre d'application de Deplhi à Delphi.NET, pour une utilisation dans Visual Studio. Je l'ai fait pour maintenir la communication inter-processus et la compatibilité architecturale entre les deux environnements de développement. Si les avantages de ce n'était pas grand, je n'aurais jamais fait la conversion.

2

Comme d'autres l'ont souligné, il n'y a pas de moyen direct d'y répondre à moins de décider d'aller jusqu'au bout pour expliquer ce qu'est Delphi et comment il se compare à dotNet.

Vous pourriez être intéressé à savoir que les dernières versions de RadStudio incluent un Delphi.NET qui s'intègre dans VS. C'est probablement votre chemin le plus court et le plus sûr vers le travail.

Pour commencer, les deux versions (bien que remarquablement différentes) ont encore assez de similarités pour la compilation croisée pour la plupart - et ce serait certainement un début.

Je ne suis pas sûr de l'interface graphique, mais tant que l'application utilise des composants grand public, il devrait y avoir des homologues dotNET. DevExpress et TMS me viennent à l'esprit, par exemple.

dernier, mais pas moins, je suis sûr que si vous avez besoin d'une aide spécifique, nous serons tous heureux de vous aider :)

Andrea

+2

Je ne recommanderais pas le portage à Delphi Prism principalement parce que le client a clairement demandé la version C# et le portage de Delphi win32 à Delphi Prism serait presque la même quantité de travail comme le portage sur C#. Delphi Prism ou Oxygene n'est pas Delphi, c'est un compilateur Object Pascal pour .NET. Real Delphi.NET (Delphi 2007 .NET) a été abandonné et pour de très bonnes raisons. Par exemple il n'y a pas de variables de classe dans Delphi Prism –

+0

C'est partiellement vrai, mais il y a quelques choses à considérer: 1) Bien que les langages soient différents, il y a toujours un grand degré de compatibilité. 2) Il est vrai que Delphi.NET n'est pas C# mais ce n'est pas un problème, car il y a une multitude de convertisseurs incluant des choses comme Reflector Plus, alors qu'il est impossible de faire correspondre Delphi et dotNET 1 à 1, c'est certainement plus rapide de cette façon (à mon avis) plutôt que toute autre option. Andrea –

+0

Le portage vers Prism conserverait également le lien avec la VCL, ce qui est un énorme plus, avec C# vous devrez utiliser un framework totalement différent. En plus du prisme, vous pouvez réutiliser (la plupart) de vos fichiers .dfm, avec C# vous devez les redessiner, beaucoup plus de travail. – Johan

1

je prendrais quelques-uns des outils automatisés pour le portage à C# juste pour vous redire la peine de porter une syntaxe différente, et après cela, tout est fait à la main.

Et il y a un livre pour les développeurs Delphi qui décrit .NET et les similitudes et les différences, .NET 2.0 for Delphi Programmers Je sais que cela est contraire, mais peut aider l'OMI

+0

Merci @Antonio Bakula. Je pense [.NET 2.0 pour les programmeurs Delphi] (http://www.amazon.com/NET-2-0-Delphi-Programmers-Shemitz/dp/1590593863) avec [Delphi for .NET Developer's Guide] (http: //www.amazon.com/Delphi-Developers-Guide-Xavier-Pacheco/dp/0672324431/ref=ntt_at_ep_dpi_1) serait vraiment utile –

+0

-1 qu'en est-il du lien vers la VCL et les fichiers DFM? C'est là où la plupart du travail est ... – Johan

+0

les outils automatisés peuvent le faire, par exemple Delphi2CS peut convertir des fichiers * .dfm en code C#. Sur leur site, ils ont déclaré que Delphi2CS peut convertir les composants VCL en C#. Je ne l'ai pas utilisé, donc je ne sais pas comment cela fonctionne, mais j'ai fait une recherche sur ce qui est nécessaire pour porter le gros système Delphi 2006 à C#, à la compagnie pour laquelle je travaillais à l'époque (2007) sur mon conseil annuler le portage tous ensemble et continuer à utiliser Delphi :) –