德尔福和COM：TLB 和维护问题

Question

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

• 经验丰富的 Delphi 和/或 COM 人员，您是否有任何解决方法来处理有问题的 TLB 接口？一些错误是：IDE 在编辑大型 TLB 期间崩溃、方法 ID 丢失、TLB 损坏等。在这里，我们还没有找到什么好的解决办法。实际上我们尝试过升级新的 2007 版本。但新的 IDE TLB 接口与我们之前发现的缺陷相同。

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

Answer 1

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

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

您可以阅读更多内容 克里斯·本森的博客.

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

这里与 TLB 接口有相同的体验：我们只是停止使用它。

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

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

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