Delphi 和 COM：TLB 和维护问题

Posted 2023-03-29

【中文标题】Delphi 和 COM：TLB 和维护问题

【英文标题】：Delphi and COM: TLB and maintenance issues

【发布时间】：2010-09-06 05:23:03

【问题描述】：

在我工作的公司，我们所有的GUI都是用C#开发的，但是应用内核主要是用Delphi 5开发的（由于历史原因），很多组件都是用COM+做的。与这种非常具体的应用程序相关的两个问题：

在 Delphi 和/或 COM 方面有经验的人，你们有什么办法可以使用有缺陷的 TLB 界面吗？ 一些错误是：IDE 在大型 TLB 的编辑期间崩溃、方法 ID 丢失、TLB 损坏等。 在这里，我们还没有找到任何好的解决方案。实际上，我们尝试升级新的 2007 版本。但是新的 IDE TLB 接口和我们之前发现的 bug 一样。

如何控制 TLB 版本？ TLB 文件是二进制格式，解决冲突非常困难。我们尝试将接口描述导出到 IDL 并提交到 CVS，但我们没有找到任何使用 Delphi 从 IDL 生成 TLB 的好方法。另外，微软提供的 MIDL 工具没有正确解析我们从 delphi 导出的 IDL 文件。

【参考方案1】：

我认为你应该好好看看 Delphi 2009。

Delphi 2009 对 COM 支持进行了更改，包括对二进制 TLB 文件的基于文本的替换。

您可以在Chris Bensen's blog 上阅读更多内容。

【参考方案2】：

在遥远的过去（在我开始为 CodeGear 工作之前），我放弃了 IDE 提供的奇怪的 Delphi 化 IDL 语言，并编写了自己的 IDL 并使用 MS midl 编译它。这在很大程度上奏效了；唯一的问题是 IIRC，确保 dispids（id 属性）在属性 getter 和 setter 的自动化接口（dispinterfaces）上是正确的——tlibimp 期望但 midl 不保证有一些不变量。

然而，既然 Delphi 2009 使用了 midl 语法的安全子集，并且在盒子中包含了该 midl 的编译器并集成到 IDE 中，这些问题应该已经成为过去。

【参考方案3】：

我们还刚刚安装了 Delphi 2009，它似乎确实改进了对 Typelibraries 的支持。然而，我使用 COM 和类型库已经有一段时间了，这里是我多年来发现的一般问题。我同意它的错误，并且一直到 Delphi 2006（我们使用 2009 之前的版本）。

在打开之前始终让每个文件都可写。这听起来很明显，但是在使用源代码控制时，有时我们会忘记这样做，并在打开文件后尝试删除只读标志——Delphi 无法处理这个问题。在打开之前确保 tlb 是可写的。 如果编辑独立类型库，您必须打开一个项目。出于某种原因，如果您自己打开一个类型库，它将不会保存。创建一个空白项目，然后打开您的类型库。出于某种原因，这允许保存类型库。 如果您的类型库被应用程序或 COM+ 使用，请确保在打开类型库之前关闭应用程序或禁用 COM+。任何打开的应用都会阻止保存类型库。

但我认为您最好的解决方案可能是升级。您也可以获得 Unicode 支持。

【参考方案4】：

使用 Delphi 2009 极大地减轻了巨大 TLB 文件的痛苦，并且我们现有对象的转换很轻松，但我们的 com 对象不使用任何第三方库。

一旦库供应商发布支持的版本，我们将迁移我们的 gui 应用程序。

【参考方案5】：

这里的 TLB 界面体验相同：我们只是停止使用它。

我们为框架的不同部分使用几个单独的 IDL 文件（手动构建），利用 #include 构造将它们包含到实际应用程序的 IDL 中，然后使用 MIDL 生成单个 tlb 并 tlibimp 它.如果应用程序没有自己的 IDL，则可以使用不同框架 TLB 文件的预编译版本。

每当框架进入新版本时，都会运行一个脚本以在 IDL 文件中的所有必要接口上重新生成 GUIDS。

多年来，这一直为我们提供了良好的服务，对于我们来说，要迁移新的 Delphi 2009 IDL/TLB 工具集，不仅必须集成到 IDE 中，而且还必须在自动化构建等方面具有通用性。迫不及待想通过一些实验弄脏我的手！