将Delphi 7应用程序迁移到.NET
https://stackoverflow.com/questions/207169
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
有关如何在Visual Studio 2005中将现有Delphi 7业务应用程序迁移到.NET 2.0的任何建议吗？
Visual Studio 2005已经被购买，该公司希望摆脱Borland / Codegear工具。
该应用程序是单个客户端服务器可执行文件，利用许多第三方UI控件和Crystal报表10进行报告。
UI中的Delphi类型以及许多SQL Server 2000存储过程都有广泛的业务逻辑。将大部分存储过程逻辑移动到.NET类中是另一个目标。
为减少对客户的影响，如果可能的话，首选一种方法而不是完全重写/转换。提前谢谢。
[更新]在这种情况下使用托管VCL有没有任何经验，好的，坏的或丑的？
解决方案
我在一家从Delphi迁移到WPF / .Net大约2007年的公司工作。我们尝试了一个接一个的方法。这很痛苦。我们总是在互操作中遇到微妙的错误。从Delphi调用WPF或Winforms并返回是很痛苦的。如果你的应用程序的各种UI控件和窗口相互调用很多，我认为你会遇到很大的成长痛苦。
如果你有能力立刻完成整个转换，我会去做。如果没有，请将您应用的部分拆分为独立部分，或与应用的其余部分进行最少的互动。
我还建议跳进.Net 2008.你为什么选择一种近4年的技术（VS 2005）？我认为，当.Net 3.5非常稳定时，选择跳入.Net 2.0是一个非常非常糟糕的商业决策。我将向管理层提供.Net 2.0的唯一正当理由是支持Windows 2000.你还有Win2k的客户吗？转换完成后，您是否还会在Win2k上拥有客户？您是否有无法迁移到XP或Vista的客户？ Win2k不支持.Net 3.0和3.5。这是我能想到的唯一缺点。
.Net 3.5和C＃2008为贵公司带来了显着的优势。与C＃2.0相比，您有许多语言功能可以加快开发时间。你有WPF，它远远优于Winforms。我认为你可以开发相同的战斗灰色Windows，你可以在Winforms中使用WPF，更快地开发它们，当你想要一些眼睛糖果时，你将使用一种可以轻松提供它的技术。如果您正在学习这种转换的新窗口平台，为什么不投资学习新的东西呢？
另外，请告诉我你实际上并没有买VS 2005.你可以买 MSDN Universal 许可证大致相同的成本，并获得微软制造的每个开发相关产品。从第三方购买，您将获得很好的折扣。
很抱歉，如果我消极的话。真诚地，祝你好运。当我想放弃.Net 3.5中的所有好东西时，我只是有倒叙。
其他提示
这对我来说听起来像是一个非常糟糕的主意。
您的产品在.NET中是否有任何技术优势，或者主要是作为微软商店的政治决定？对于客户端 - 服务器，Delphi非常难以击败。我已经使用过VS2005 / 8，它真的非常真实，真诚地不如Delphi for Win32开发。但是，如果你要在网上迁移到网络，那么VS有一定的优势。
如果顽固的商界人士不再拒绝使用Delphi，那么KiwiBastard是正确的，IMO。首先转换为Delphi.NET，然后从那里迁移到VS2005。或2010年，因为这是一个更现实的时间表：）
我之前曾在一家想要从Delphi转换为C＃.NET的公司工作，因为.NET完全是酷炫闪亮的。他们带来了更多具有大量C＃经验的开发人员，并且最终将开发人员的3倍时间用于将应用程序移植到C＃，然后它在Delphi中第一次写入它以获得非常少的额外ROI（一些在此过程中添加了新功能）。此外，客户对应用程序性能或UI不满意。
案例研究后的案例研究表明，重写是一个坏主意。 （帽子提示 kogus ）
如果你必须转移到.NET（是的，我知道，你没有做出决定，某人信息少）那么我会建议使用 Delphi for .NET 或 RemObjects Oxygene 。后者是Visual Studio插件。但即使是 RemObjects Oxygene的首席软件架构师marc hofman 也说过这是一个坏主意。将一个完美的应用程序迁移到.NET“只是因为。”
如果您可以等待Delphi Prism，这也是一个Visual Studio插件，预计将在今年晚些时候推出。
零碎转换意味着更改本机Delphi代码以使用COM，因此.NET端可以与Delphi共存（或者可能使用其他一些技术 - 很难说）
如果可以的话，首先将应用程序转换为Delphi.NET可能会更容易，那么至少.NET位将能够更容易地进行通信。
只是一个想法。
远离CodeGear / Borland工具基本上消除了任何基于Delphi .NET的解决方案并完全重写了您的应用程序。
我希望下面的答案可以帮助您做出决定。
根据经验（用一组人重写了Delphi应用程序），它归结为以下两种选择中的任何一种。
但首先要警告：您至少需要花费大量的时间来编写当前的Delphi应用程序。
在我们的案例中，这项工作是有道理的，因为旧的Delphi应用程序（实际上它是Kylix）由于各种原因而终止了。 我们的重写包括两部分：重写有限的额外功能，然后是许多额外的功能（第一部分的设计已考虑到第二部分）。
回到你的选择：
1-在Visual Studio中的C＃或VB.NET中完全重写
2-使用RemObjecs的Oxygene（一种Visual Studio插件，其语法与Delphi语法非常相似），部分重用现有的Delphi业务层代码。 CodeGear将很快（可能在2008年底之前）提供Prism，它也将集成到Visual Studio中。
由于.NET数据访问和UI与Delphi完全不同，因此您必须从头开始执行这些操作（方案1和方案2）。与Visual Studio 2005相比，Visual Studio 2008提供了许多好处。
没有逐步进行此迁移的事情，因为您在此处进行了完整的平台更改，这是一种全有或全无的方法。
这两种情况都需要相当长的时间（即使你有Delphi的经验，让自己习惯于.NET世界需要时间）。
Visual Studio可以与Crystal Reports交互，并且与SQL Server配合良好。
由于Visual Studio 2008提供了很多好处（不仅是.NET 3.5，而且还有生产力方面的优势），因此您最好使用它。 在UI方面，您需要在WinForms（即Windows Forms）和Windows Presentation Foundation（又名WPF）之间做出平衡选择。
如果是1对1重写，您可能希望坚持使用WinForms，因为它对您所拥有的内容很熟悉。您可能需要使用一些第三方组件来启动UI; DevExpress是一个很好的选择，因为它们在Delphi和Visual Studio中有类似的组件。
但是如果你想为未来的眼睛糖果，那么你可能会考虑WPF。准备好比WinForms更陡峭的学习曲线，因为它与您习惯的非常不同。
如果您决定继续使用Delphi，您可能需要考虑使用VCL进行Web（也称为IntraWeb）和Delphi 2009（自Delphi 7 6年前宣布以来，Delphi世界已经发生了很多变化）。
祝你好运做出选择！
- 的Jeroen
我建议从RemObjects查看Hydra。它基本上为您提供了com接口，并提供了一个观察器模式，用于连接Delphi和.Net应用程序。您可以在Delphi应用程序内的面板上显示.Net表单。这提供了一个很好的迁移路径，您可以在将功能迁移到.Net时逐位替换Delphi代码。
对我来说，问题是：你会使用哪种语言？我希望C＃而不是VB.Net。 （在这个用例中，所有尴尬的政治都不清楚。）
接下来你可能会听到的是，那里有转换器可以帮助你做到这一点。我们刚刚对这些转换器（Delphi 7到C＃）进行了评估，非常非常！失望。
我可以建议妥协吗？ Delphi Prism怎么样？它是VS2008中的Delphi。当然，你仍然有Delphi，因此你也有Codegear，但你也有VS（正如你公司所期望的那样）。
有一份科学报告称，John Brant，Don Roberts等人将150万行德尔福项目成功转型为C＃。他编写了一个Delphi解析器，一个C＃生成器和许多关于AST的转换规则。逐步扩展规则集，进行日常构建，大量单元测试，以及对难度较大的Delphi部分进行一些重写，这使他成为一个由4人组成的团队，其中包括一些原始开发人员，以及深度Delphi和C＃知识，在18个月内迁移软件。约翰布兰特＆amp; Don Roberts是重构浏览器和SmaCC编译器构建工具包的原始开发人员，你不太可能那么快。
虽然这是一项重大投资，但它与原始开发项目的规模并不相同。作者指出，如Jeroen所指出的那样，没有工具或使用单次射击工具的直接重写很可能导致这种情况，尤其是在考虑新要求的情况下。
作者在不同项目的同一平台上进行了大规模的重构，完全取代了持久性基础设施。这可能与旧的（BDE？）项目相关。
只有您才能真正决定是否可以采用逐件方法。例如，应用程序可以轻松划分，也可以是与所有业务逻辑过于强烈耦合的所有形式。从技术上讲，这是可能的，但一切都取决于代码库的结构如何。
