有关如何在 Visual Studio 2005 中将现有的 Delphi 7 业务应用程序迁移到 .NET 2.0 的任何建议？
Visual Studio 2005 已被购买，该公司希望摆脱 Borland/Codegear 工具。
该应用程序是单个客户端服务器可执行文件，利用许多第 3 方 UI 控件和 Crystal 报表 10 进行报告。
UI 中的 Delphi 类型以及许多 SQL Server 2000 存储过程中分布着广泛的业务逻辑。将大部分存储的 proc 逻辑移动到 .NET 类中是另一个目标。
为了减少对客户的影响，如果可能的话，最好采用逐个方法而不是完全重写/转换。提前致谢。
[更新] 有没有人有任何经验，好的，坏的或丑陋的，使用托管 VCL 来处理这种类型的场景？
这听起来对我来说是一个非常糟糕的主意。
您的产品在 .NET 中是否有任何技术优势，或者成为 Microsoft 商店主要是出于政治决定？对于客户端-服务器，Delphi 很难被击败。我用过VS2005/8，它在Win32开发上真的真的真的没有Delphi那么好。但是，如果您打算在以后迁移到 Web，那么 VS 具有明显的优势。
如果顽固的商业人士只是拒绝再使用 Delphi，那么 KiwiBastard 是正确的，IMO。首先转换为 Delphi.NET，然后从那里迁移到 VS2005。或者 2010 年，因为那是一个更现实的时间表 :)
我在一家公司工作，该公司大约在 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 通用许可证，并获得 Microsoft 制造的所有与开发相关的产品。从第 3 方购买，您将获得很好的折扣。
对不起，如果我是负面的。真诚地，祝您迁移顺利。当我想到不得不放弃 .Net 3.5 中的所有好东西时，我只是有闪回。
我之前曾在一家公司工作，该公司想从 Delphi 转换为 C#.NET，因为 .NET 非常酷炫。他们引入了更多具有丰富 C# 经验的开发人员，最终将应用程序移植到 C# 花费了开发人员两倍的 3 倍时间，然后它确实在 Delphi 中首次编写它，但额外的投资回报率非常低（一些在此过程中添加了新功能）。此外，客户对应用程序性能或 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 部分重用现有的 Delphi 业务层代码（一个 Visual Studio 插件，其语法与 Delphi 语法非常相似）。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 窗体）和 Windows Presentation Foundation（又名 WPF）之间做出平衡的选择。
如果它是一对一的重写，您可能希望坚持使用 WinForms，因为它对您所拥有的内容很熟悉。您可能需要使用一些 3rd 方组件来启动您的 UI；DevExpress 是一个不错的选择，因为它们在 Delphi 和 Visual Studio 中有类似的组件。
但是，如果您想追求未来的视觉效果，那么您可能会考虑 WPF。准备好在这里比 WinForms 更陡峭的学习曲线，因为它与您习惯的非常不同。
如果您决定继续使用 Delphi，您可能需要研究 VCL for Web（又名 IntraWeb）和 Delphi 2009（自 6 年前宣布 Delphi 7 以来，Delphi 世界发生了很大变化）。
祝您选择顺利！
——杰伦
我建议从 RemObjects 看 Hydra。它基本上为您提供了 com 接口，并为您的 Delphi 和 .Net 应用程序之间的接口提供了一个观察者模式。您可以在 Delphi 应用程序内的面板上显示 .Net 表单。这提供了一个很好的迁移路径，您可以在将功能迁移到 .Net 时一点一点地替换您的 Delphi 代码。
John Brant、Don Roberts 等人发表了一份科学报告，将 150 万行的 Delphi 项目成功转换为 C#。他在 AST 上编写了一个 Delphi 解析器、一个 C# 生成器和许多转换规则。逐渐扩展规则集，进行日常构建，大量单元测试，以及一些困难的 Delphi 部分的重写，使他有了一个 4 人的团队，其中一些原始开发人员具有深厚的 Delphi 和 C# 知识，可以迁移软件在 18 个月内。John Brant 和 Don Roberts 作为重构浏览器和 SmaCC 编译器构建工具包的原始开发人员，您不太可能走得那么快。
尽管这是一项重大投资，但它与“原始开发项目的规模不同”。作者指出，正如 Jeroen 所指出的那样，直接重写，无需工具或使用单次工具，很可能会导致这种情况，尤其是在考虑到新需求的情况下。
作者在为不同项目留在同一平台上的同时进行了大规模重构，完全取代了持久性基础设施。这可能与基于旧（BDE？）的项目有关。
对我来说，问题是：您将使用哪种语言？我确实希望 C# 而不是 VB.Net。（由于这个用例中的所有尴尬政治，这无论如何都不清楚。）
接下来你可能会听到有一些转换器可以帮助你做到这一点。我们刚刚对此类转换器（Delphi 7 到 C#）进行了评估，非常棒！失望的。
我可以建议妥协吗？德尔福棱镜怎么样？它是VS2008中的Delphi。当然，您仍然拥有 Delphi 和 Codegear，但您也拥有 VS（正如您的公司所期望的那样）。
只有您才能真正决定是否可以使用逐件方法。例如，应用程序是否可以轻松拆分，或者所有表单与所有业务逻辑的耦合过于紧密。从技术上讲这是可能的，但这一切都取决于代码库的结构。