Delphi 4和/或Delphi 5可执行文件是否可以集成到C#应用程序中

这个问题的基本前提似乎是围绕Delphi核心的C#包装器更容易维护和运行，如果不是这样，那么创建包装器的想法就变得不太有用了。我认为这是一个错误的概念。

想象一下，我制作了一个可以与望远镜对话的应用程序。它做得很完美。在这种情况下，我可能只提取望远镜通信部分并将其放入DLL中，然后用C#编写一个用户界面，使用Delphi DLL来完成与望远镜的通信任务。然而，除非你的Delphi应用程序已经以一种良好的方式构建，除非像这个望远镜通信库这样的任务已经存在，否则你不会发现提取Delphi应用软件的任何部分并从C#中使用它是非常困难的。如果存在这种情况，我会使用本机Delphi DLL函数导出，并从C#调用它们。这不是在使用现有的delphi可执行文件，并且需要花费许多小时的工作才能将delphi应用程序的一部分重构为可以从C#中使用的东西。

另一个答案提到COM服务器，虽然这是可能的，但它不会让事情变得更容易；就像关于正则表达式的老笑话；当你有一个问题，并试图通过使用正则表达式来解决它时，现在你有两个问题。当您尝试使用COM服务器来隐藏现有的应用程序，并使用C#在其上编写一个全新的UI时，情况也是如此。实际上，用这种方式改进、调试和继续开发它需要更多的技术技能，而不是纯粹用delphi或C#进行开发。这是一个负节省的努力。

您没有提供关于Delphi应用程序的功能的信息，但让我们假设它是一个业务线或垂直市场应用程序，它读取一些文件格式，或者执行一些通信协议，甚至连接到一些旧数据库，您不想重写这些文件格式。

如果你所说的C#用户界面是指永远不显示Delphi应用程序的用户界面并用C#用户界面替换它，那么几乎可以肯定的是，你的想法不会让任何事情变得更好，只会让事情变得更糟。您的死锁要么来自于没有熟练的delphi开发人员，要么来自于缺乏能够理解现有应用程序功能的聪明开发人员。

当你处于这种情况时，解决方案通常是人为的；要么雇佣一名熟练的delphi开发人员并将应用程序带入现代delphi时代（DelphiXE2），要么雇佣一位熟练的非delphi开发员并将应用软件移植到其他语言。任何建议在delphi应用程序之上写一个"包装器"的人，如果认为这会让它"更容易"，显然会觉得无法重写现有的应用程序。

当然，我对delphi应用程序的作用还不够了解，但在我看来，这听起来确实像是"恐惧驱动"的决策。封装旧代码几乎从来都不是一个好主意，而且在大多数情况下，这只是造成更多问题。

可以从C#运行Delphi.exe。但我想这不是你的观点。

您可以使用COM服务器，这是标准的，但需要在计算机上注册COM对象（通过运行regsrv32.exe）。部署起来并不那么容易。

或者，您可以将Delphi代码定义为库，然后从C#代码加载并执行.dll。

如果您更喜欢从Delphi 4或5访问C#对象（即访问C#RTTI），则必须使用一些低级单元，如用于Delphi Win32的VCL-.Net互操作的托管扩展。它非常完整，可以与旧版本的Delphi一起使用（遗憾的是，比Hydra更高级的东西将不支持Delphi 4或5）。

编辑

另一种可能的简单通信是GDI消息。您可以从C#代码中发送GDI命令来控制Delphi应用程序，但使用PostMessage（）API调用。

当然。C#可以调用任何.exe。只需使用进程。启动：

http://www.dotnetperls.com/process-start

http://msdn.microsoft.com/en-us/library/system.diagnostics.process.aspx

Delphi 5支持实现COM服务器功能（不知道早期版本，D2肯定不知道）。

如果你有可用的来源，

• 添加类型库和类型库中定义的接口的COM实现，

• 注册可执行文件（由于Delphi魔术，通常在启动时自动完成）

• 遵循MSDN上的步骤：向.NET Framework 公开COM组件