在我们的项目，我们在我们的asp.net应用程序重用的Delphi代码大量的通过COM。
像这样：遗留的Delphi DLL =>的Delphi COM包装=> .NET互操作程序=> asp.net（MVC）
我们有关于访问冲突，DLL的，等卸一些问题......我现在已经移植了一些使用传统的DLL直接通过P /调用代码。
当我看到关于资源和COM的P / Invoke，人们几乎总是建议使用COM。 这是为什么？ 不会的P / Invoke具有以下优点：
PInvoke的是一个非常好的工具，但它肯定是COM的替代品。 PInvoke的只支持简单的功能与C语法，COM可以让你实现一个对象模型。 就拿类的Microsoft.Office.Interop命名空间，例如，他们都是纯粹的COM类，没有包装。 与PInvoke的互操作做办公室将是极其痛苦。
与PInvoke的另一个核心问题，它通常是客户端程序员的负担写的声明。 这个人最不容易得到他们的权利。 一个COM作者可以发布一个自动生成的类型库，很像在.NET组件的元数据。 极大地消除了错误的可能性，并没有通过超越项目+添加引用客户端程序员所需要的工作。
解决你的子弹：
签出代码总是会使用正确的DLL，而不是最后的注册COM
你仍然受到到Windows的找到适当的DLL变幻莫测。 避免事故发生的唯一的好方法是将DLL存储在同一目录下的EXE。 这是在COM相当可能的，所有你所要做的就是创建一个名为的空文件yourapp.exe.local
多个版本可以在服务器上并行运行（例如：开发，测试和QA）
在COM也不是问题，通过使用上述技术或通过使用免费REG-清单
没有更多的COM注册的麻烦
因此不需要注册使用免费REG-清单。 很简单的事，只需设置基准为True的隔离性能。
远远高于COM通信速度更快（文章我读表明的速度提高了30％）
它比COM 慢得多 。 您可以通过承担作出额外收费的后期绑定COM通过IDispatch调用，这是大致的使用反射来拨打电话一样贵。
还有第三个办法做到本地代码互操作：写在C ++ / CLI语言的托管类包装。 该技术在.NET框架大量使用，特别是在mscorlib.dll，System.Data和PresentationFramework中，具有上的本机代码强依赖性组件。 但是不很适合德尔福，它最适合本地代码，可以很容易地从C或C ++调用。
