将Delphi 7应用程序迁移到.NET

时间:2008-10-16 01:51:14

标签: .net delphi migration

有关如何在Visual Studio 2005中将现有Delphi 7业务应用程序迁移到.NET 2.0的任何建议吗?

Visual Studio 2005已经被购买,该公司希望摆脱Borland / Codegear工具。

该应用程序是单个客户端服务器可执行文件,利用许多第三方UI控件和Crystal报表10进行报告。

UI中的Delphi类型以及许多SQL Server 2000存储过程都有广泛的业务逻辑。将大部分存储过程逻辑移动到.NET类中是另一个目标。

为减少对客户的影响,如果可能的话,首选一种方法而不是完全重写/转换。提前谢谢。

[更新]在这种情况下使用托管VCL有没有任何经验,好的,坏的或丑的?

9 个答案:

答案 0 :(得分:9)

这对我来说听起来像really bad idea

您的产品在.NET中是否有任何技术优势,或者主要是作为微软商店的政治决定?对于客户端 - 服务器,Delphi非常难以击败。我已经使用过VS2005 / 8,它真的非常真实,真诚地不如Delphi for Win32开发。但是,如果你要在网上迁移到网络,那么VS有一定的优势。

如果顽固的商界人士不再拒绝使用Delphi,那么KiwiBastard是正确的,IMO。首先转换为Delphi.NET,然后从那里迁移到VS2005。或2010年,因为这是一个更现实的时间表:)

答案 1 :(得分:8)

我在一家从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中的所有好东西时,我才会有闪回。

答案 2 :(得分:8)

我之前曾在一家想要从Delphi转换为C#.NET的公司工作,因为.NET完全是酷炫闪亮的。他们带来了更多具有大量C#经验的开发人员,并且最终将开发人员的3倍时间用于将应用程序移植到C#,然后它在Delphi中第一次编写它以获得非常少的额外ROI(一些在此过程中添加了新功能)。此外,客户对应用程序性能或UI不满意。

案例研究后的案例研究显示rewriting is a bad idea。 (帽子提示到kogus

如果您必须转移到.NET(是的,我知道,您没有做出决定,信息少的人),那么我建议使用Delphi for .NET或{{ 3}}。后者是Visual Studio插件。但是即使RemObjects Oxygene已经说过将一个完美的应用程序迁移到.NET“这只是因为。”这是一个坏主意。

如果您可以等待Delphi Prism,这也是一个Visual Studio插件,预计将在今年晚些时候推出。

答案 3 :(得分:3)

零碎转换意味着更改本机Delphi代码以使用COM,因此.NET端可以与Delphi共存(或者可能使用其他一些技术 - 很难说)

如果可以的话,首先将应用程序转换为Delphi.NET可能会更容易,那么至少.NET位将能够更容易地进行通信。

只是一个想法。

答案 4 :(得分:2)

远离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

答案 5 :(得分:2)

我建议从RemObjects查看Hydra。它基本上为您提供了com接口,并提供了一个观察器模式,用于连接Delphi和.Net应用程序。您可以在Delphi应用程序内的面板上显示.Net表单。这提供了一个很好的迁移路径,您可以在将功能迁移到.Net时逐位替换Delphi代码。

答案 6 :(得分:1)

对我来说,问题是:你会使用哪种语言?我希望C#而不是VB.Net。 (在这个用例中,所有尴尬的政治都不清楚。)

接下来你可能会听到的是,那里有转换器可以帮助你做到这一点。我们刚刚对这些转换器(Delphi 7到C#)进行了评估,非常非常!失望。

我可以建议妥协吗? Delphi Prism怎么样?它是VS2008中的Delphi。当然,你仍然有Delphi,因此你也有Codegear,但你也有VS(正如你公司所期望的那样)。

答案 7 :(得分:1)

有一份科学报告称,John Brant,Don Roberts等人将150万行德尔福项目成功转型为C#。他编写了一个Delphi解析器,一个C#生成器和许多关于AST的转换规则。逐步扩展规则集,进行日常构建,大量单元测试以及对难度较大的Delphi部分进行一些重写,这使他成为了一个由4人组成的团队,其中包括一些原始开发人员,以及深度Delphi和C#知识,在18个月内迁移软件。约翰布兰特& Don Roberts是重构浏览器和SmaCC编译器构建工具包的原始开发人员,你不太可能那么快。

虽然这是一项重大投资,但它与原始开发项目的规模并不相同。作者指出,如Jeroen所指出的那样,没有工具或使用单次射击工具的直接重写很可能导致这种情况,尤其是在考虑新要求的情况下。

作者在不同项目的同一平台上进行了大规模的重构,完全取代了持久性基础设施。这可能与旧的(BDE?)项目相关。

答案 8 :(得分:0)

只有您才能真正决定是否可以采用逐件方法。例如,应用程序可以轻松划分,也可以是与所有业务逻辑过于强烈耦合的所有形式。从技术上讲,这是可能的,但一切都取决于代码库的结构如何。