将 Delphi 7 应用程序迁移到 .NET
关于如何在 Visual Studio 2005 中将现有 Delphi 7 业务应用程序迁移到 .NET 2.0 有什么建议吗？
Visual Studio 2005 已经被购买，该公司希望放弃 Borland/Codegear 工具。
该应用程序是单个客户端服务器可执行文件，利用许多第 3 方 UI 控件和 Crystal reports 10 进行报告。
UI 中的 Delphi 类型以及许多 SQL Server 2000 存储过程中分布着广泛的业务逻辑。 将大部分存储过程逻辑移至 .NET 类中是另一个目标。
为了减少对客户的影响，如果可能的话，最好采用逐步的方法，而不是完全重写/转换。 提前致谢。
[更新] 有没有人有过在此类场景中使用托管 VCL 的经验，无论好坏还是丑陋？
Any advice on how to migrate an existing Delphi 7 business application to .NET 2.0 in Visual Studio 2005?
Visual Studio 2005 has already been purchased, the company wants to move away from the Borland/Codegear tools.
The application is a single client server executable, utilizing a number of 3rd party UI controls and Crystal reports 10 for reporting.
There is extensive business logic spread across Delphi types in the UI as well as many SQL Server 2000 stored procedures. Moving much of the stored proc logic into .NET classes is another goal.
To reduce impact on customers, a piece by piece approach rather than a complete re-write/conversion would be preferred, if possible. Thanks in advance.
[Update] Has anyone had any experience, good, bad or ugly, using Managed VCL for this type of scenario?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
放弃 CodeGear/Borland 工具基本上消除了任何基于 Delphi .NET 的解决方案和对应用程序的完全重写。
希望我下面的回答对您的决定有所帮助。
根据经验（与一群人一起重写了 Delphi 应用程序），它可以归结为以下两个选择之一。
但首先要警告：您至少需要花费编写当前 Delphi 应用程序所需的全部开发精力。
在我们的例子中，这项工作是有必要的，因为旧的 Delphi 应用程序（实际上是 Kylix）由于各种原因已经终止。
我们的重写包括两部分：用有限的额外功能重写，然后是大量额外功能（第一部分的设计已经考虑了第二部分）。
回到您的选择：
1- 在 Visual Studio 中用 C# 或 VB.NET 进行完全重写
2- 通过使用 RemObjecs 中的 Oxygene（一个 Visual Studio 插件，其语法与德尔福语法）。 CodeGear 很快就会提供 Prism（可能在 2008 年底之前），它也将集成到 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）之间做出平衡选择。
如果是一对一重写，您可能希望坚持使用 WinForms，因为它对您所拥有的内容很熟悉。 您可能需要使用一些第三方组件来让您的 UI 正常运行； DevExpress 是一个不错的选择，因为它们在 Delphi 和 Visual Studio 中具有类似的组件。
但如果您想要未来的视觉效果，那么您可能会考虑 WPF。 准备好迎接比 WinForms 更陡峭的学习曲线，因为它与您习惯的非常不同。
如果您决定继续使用 Delphi，您可能需要研究 VCL for the Web（又名 IntraWeb）和 Delphi 2009（自 6 年前发布 Delphi 7 以来，Delphi 世界发生了很多变化）。
祝您做出选择好运！
——杰罗恩
Moving away from CodeGear/Borland tools basically eliminates any Delphi .NET based solution and a total rewrite of your application.
I hope my answer below helps with your decisions.
From experience (having rewritten a Delphi application with a team of people) it boils down to either of two choices below.
But first a warning: you will take at least the total development effort it took to write your current Delphi application.
In our case, this effort was warranted since the old Delphi application (which in fact it was Kylix) had an end-of-life because of various reasons.
Our rewrite consisted of two parts: rewrite with limited extra functionality followed by a lot of extra functionality (the design of the first part already took the second part into account).
Back to your choices:
1- a total rewrite in C# or VB.NET in Visual Studio
2- a partial reuse of your existing Delphi business layer code by using Oxygene from RemObjecs (a Visual Studio plugin with a syntax that is very similar to the Delphi syntax). CodeGear will offer Prism soon (likely before the end of 2008), which will also integrate into Visual Studio.
Because .NET data access and UI are totally different from Delphi, you will have to do these from scratch (both for scenario 1 and 2). Visual Studio 2008 offers a lot of benefits here over Visual Studio 2005.
There is no such thing as doing this migration gradually, since you do a complete platform change here, it is an all or nothing approach.
Both scenario's will take a considerable amount of time (even though you have Delphi experience, getting yourself accustomed in the .NET world will take time).
Visual Studio can interact with Crystal Reports, and goes well with SQL Server.
Since Visual Studio 2008 offers a lot of benefits (not only .NET 3.5, but also productivity wise), you'd better go with that.
On the UI side, you need to make a balanced choice between WinForms (aka Windows Forms) and Windows Presentation Foundation (aka WPF).
If it is a 1-to-1 rewrite, you might want to stick with WinForms as it is familiar to what you have. You probably need to use some 3rd party components to get your UI going; DevExpress is a good choice here as they have similar components in Delphi and Visual Studio.
But if you want to go for future eye candy, then you might consider WPF. Be prepared for a steeper learning curve here than WinForms as it is very different from what you are used to.
If you decide to stay with Delphi, you might want to look into VCL for the Web (aka IntraWeb) and into Delphi 2009 (a lot has changed in the Delphi world since Delphi 7 was announced 6 years ago).
Good luck making your choices!
--jeroen
我建议从 RemObjects 中查看 Hydra。 它基本上为您提供了 com 接口，并为 Delphi 和 .Net 应用程序之间的接口提供了观察者模式。 您可以让 .Net 表单出现在 Delphi 应用程序内的面板上。 这提供了一个很好的迁移路径，您可以在将功能迁移到 .Net 时一点一点地替换 Delphi 代码。
I would suggest looking at Hydra from RemObjects. It basically raps the com interface for you and provides an observer pattern for interfacing between your Delphi and .Net application. You can have .Net forms appear on panels inside your Delphi app. This provides a nice migration path where you replace your Delphi code bit by bit as you migrate functionality to .Net.
John Brant、Don Roberts 等人曾发表过一份关于将 150 万行 Delphi 项目成功转换为 C# 的科学报告。 他编写了一个 Delphi 解析器、一个 C# 生成器以及许多关于 AST 的转换规则。 逐渐扩展规则集、进行日常构建、大量单元测试以及对困难的 Delphi 部分进行一些重写，使他能够拥有一个 4 人的团队，其中包括一些具有深厚 Delphi 和开发经验的原始开发人员。 C# 知识，18 个月内迁移软件。 约翰·布兰特 Don Roberts 是重构浏览器和 SmaCC 编译器构建工具包的原始开发者，你不可能走得那么快。
尽管这是一项重大投资，但其“规模与最初开发项目的规模相差甚远”。 作者指出，正如 Jeroen 所指出的，在没有工具或使用单次工具的情况下进行直接重写很可能会导致这种情况，特别是在考虑到新需求的情况下。
作者在不同项目的同一平台上进行了大规模重构，完全取代了持久性基础设施。 这可能与基于较旧（BDE？）的项目相关。
There has been a scientific report of a successfull transformation of a 1.5 million line Delphi Project to C# by John Brant, Don Roberts et al. He wrote a Delphi parser, a C# generator and lots of transformation rules on the AST. Gradually extending the set of rules, doing a daily build, lots of unit tests, and some rewriting of difficult Delphi parts allowed him with a team of 4, among which some of the original developers, with deep Delphi & C# knowledge, to migrate the software in 18 months. John Brant & Don Roberts being the original developers of the refactoring browser and the SmaCC compiler construction kit, you are unlikely to be able to go that fast.
Though this was a significant investment, it is nowhere 'the same size as the original development'. The authors note that a straightforward rewrite, without tools or with a single-shot tool, as noted by Jeroen, is very likely to result in that, especially if new requirements are taken into account.
The authors have done large scale refactorings while staying on the same platform for a different project, completely replacing the persistence infrastructure. This could be relevant for older (BDE?) based projects.
对我来说，问题是：您将使用哪种语言？ 我确实希望使用 C# 而不是 VB.Net。 （由于这个用例中存在所有尴尬的政治因素，这无论如何都不清楚。）
接下来您可能会听到的是，有转换器可以帮助您做到这一点。 我们刚刚对此类转换器（Delphi 7 到 C#）进行了评估，结果非常好！ 失望的。
我可以建议一个妥协方案吗？ 德尔福棱镜怎么样？ 这是VS2008中的Delphi。 当然，您仍然有 Delphi，因此还有 Codegear，但您也有 VS（正如您的公司所期望的那样）。
For me the question would be: which language would you be using? I do hope C# and not VB.Net. (With all the awkward politics in this usecase this is not clear by any means.)
The next you will probably hear is that there are converters out there that will help you doing this. We just went through an evaluation of such converters (Delphi 7 to C#) and were very! disappointed.
May I suggest a compromise? How about Delphi Prism? It is Delphi in VS2008. Sure, you still have Delphi and therefore Codegear, but you also have VS (as your company expects you to).
只有您才能真正决定是否可以采取逐条处理的方法。 例如，应用程序是否可以轻松划分，或者所有表单与所有业务逻辑的耦合是否过于紧密。 从技术上讲这是可能的，但一切都取决于代码库的实际结构。
Only you can really decide if a piece by piece approach is possible. For example can the application be divided up easily or are all the forms too strongly coupled with all the business logic. Technically it's possible but all depends on how the code base is structured really.
对我来说，这听起来像是一个非常糟糕的主意。
您的产品采用 .NET 是否有任何技术优势，或者成为 Microsoft 商店主要是一个政治决定？ 对于客户端-服务器来说，Delphi 很难被击败。 我用过VS2005/8，对于Win32开发来说，它确实不如Delphi。 但如果您打算将来迁移到网络，那么 VS 具有明显的优势。
如果顽固的商业人士只是拒绝再使用 Delphi，那么 KiwiBastard 是正确的，IMO。 首先转换为 Delphi.NET，然后从那里迁移到 VS2005。 或者 2010 年，因为那是更现实的时间表:)
That sounds like a really bad idea to me.
Is there any technological advantage for your product to be in .NET, or is it mostly a political decision to be a Microsoft shop? For client-server, Delphi is pretty tough to beat. I've used VS2005/8 and it is really and truly genuinely and sincerely not as good as Delphi for Win32 development. But if you're going to migrate to the web down the road, then VS has definite advantages.
If stubborn business folks simply refuse to use Delphi anymore, then KiwiBastard is correct, IMO. Convert first to Delphi.NET, then migrate from there to VS2005. Or 2010, since that is a more realistic timeline :)
我在一家公司工作，该公司大约在 2007 年从 Delphi 迁移到 WPF/.Net。我们尝试了一种逐步的方法。 很痛苦。 我们总是在互操作中遇到微妙的错误。 从 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 优越得多。 我认为，您可以开发与使用 WPF 在 Winforms 中获得的相同的战舰灰色 Windows，开发速度更快，并且当您想要一些养眼的东西时，您将使用可以轻松提供它的技术。 如果您正在学习用于此转换的新窗口平台，为什么不投资学习新东西呢？
另外，请告诉我您实际上并没有购买 VS 2005。您可以购买 MSDN Universal 许可证的成本大约相同，并获得 Microsoft 制造的所有开发相关产品。 从第 3 方购买，您将获得很好的折扣。
抱歉，如果我的结果是负面的。 真诚地祝您迁移顺利。 当我想到必须放弃 .Net 3.5 中的所有好东西时，我的脑海里闪现出这样的情景。
I worked at a company that was migrating from Delphi to WPF/.Net circa 2007. We tried a piece by piece approach. It was painful. We were always running into subtle bugs in the interop. Calling from Delphi to WPF or Winforms and back is painful. If the various UI controls and windows of your application call on each other a lot, I think you will experience significant growing pains.
If you can afford to do the whole conversion at once I would go for it. If not, split out the parts of your app that are stand-alone or have the minimum of interactions with the rest of the app.
I would also suggest jumping into .Net 2008. Why are you picking a technology that is almost 4 years old (VS 2005)? I think it is a very, very bad business decision to choose to jump into .Net 2.0 when .Net 3.5 is very stable. The only valid reason I would ever present to management for .Net 2.0 would be to support Windows 2000. Do you still have customers on Win2k? Will you still have customers on Win2k by the time your conversion is complete? Do you have customers you cannot get to move to XP or Vista? .Net 3.0 and 3.5 are not supported in Win2k. That is the only downside I can think of.
.Net 3.5 and C# 2008 offer significant advantages for your company. You have a number of language features that will accelerate develop time compared to C# 2.0. You have WPF, which is vastly superior to Winforms. I would argue that you can develop the same batteleship-gray Windows you would get in Winforms with WPF, develop them faster, and when you want some eye-candy you will be using a technology that can easily provide it. If you are learning a new windowing platform for this conversion, why not invest in learning the new stuff?
Also, please tell me you didn't actually buy VS 2005. You can buy an MSDN Universal license for about the same cost, and get every development related product Microsoft makes. Buy it from a 3rd party and you will get a good discount.
Sorry if I came off negative. Sincerely, good luck on the migration. I just have flashbacks when I think of having to give up all the goodies in .Net 3.5.
我之前在一家公司工作过，该公司希望从 Delphi 转换为 C#.NET，因为 .NET 非常又酷又闪亮。 他们引入了更多具有丰富 C# 经验的开发人员，最终将应用程序移植到 C# 所需的时间是第一次在 Delphi 中编写的开发人员的 3 倍，而额外的投资回报率却非常低（一些在此过程中添加了新功能）。 另外，客户对应用程序性能或用户界面不满意。
一个又一个的案例研究表明，重写是一个坏主意。 （向 kogus 致敬）
如果您必须迁移到 .NET（是的，我知道，您没有做出决定，信息较少的人做了）那么我建议使用 Delphi for .NET< /a> 或 RemObjects Oxygene。 后者是 Visual Studio 插件。 但即使 RemObjects Oxygene 的首席软件架构师 marc hofman 也表示，将完美运行的应用程序迁移到 .NET“只是因为”。
如果您可以等待 Delphi Prism，它也是一个 Visual Studio 插件，预计将于今年晚些时候推出。
I previously worked at a company that wanted to convert from Delphi to C#.NET because .NET is all cool and shiny. They brought in some more developers who had a lot of C# experience and it ended up taking 3 times the developers twice as long to port the application to C# then it did to write it the first time in Delphi for very little additional ROI (a few new features were added in the process). Plus the customers were not happy with the application performance or the UI.
Case study after case study shows that rewriting is a bad idea. (Hat tip to kogus)
If you must move to .NET (yeah, I know, you didn't make the decision, someone with less information did) then I would suggest using Delphi for .NET or RemObjects Oxygene. The latter being a Visual Studio plug-in. But even marc hofman, the Chief Software Architect of RemObjects Oxygene has said it is a bad idea to migrate a perfectly working application to .NET "just because."
If you can wait for Delphi Prism, which is also a Visual Studio add-in and is expected to be out later this year.
逐步转换意味着更改本机 Delphi 代码以使用 COM，以便 .NET 端可以与 Delphi 共存（或者可能使用其他一些技术 - 很难说）
如果可以的话，将应用程序转换为 Delphi 可能会更容易首先是 .NET，然后至少 .NET 位能够更轻松地进行通信。
只是一个想法。
A piecemeal conversion would mean changing the native Delphi code to use COM so the .NET side can co-exist with Delphi (or possibly using some other technology - hard to say)
If you can, it might be easier to convert the app to Delphi.NET first, then at least the .NET bits will be able to communicate a little easier.
Just a thought.