Delphi和COM：TLB和维护问题

在我工作的公司中，我们使用C＃开发所有GUI，但是由于历史原因，应用程序内核主要是在Delphi 5中开发的，其中许多组件是在COM +中制成的。与这种非常特定类型的应用有关，我有两个问题：

• 在Delphi和/或COM方面经验丰富的人，您有没有使用多虫的TLB界面的工作环境？
  其中一些错误是：在大型TLB的版本中IDE崩溃，方法ID丢失，TLB损坏等。
  在这里，我们没有找到任何好的解决方案。实际上，我们尝试升级新的2007版本。但是新的IDE TLB界面具有我们之前发现的错误。

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

---

我认为您应该对Delphi 2009有所了解。

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

您可以在Chris Bensen的博客上阅读更多内容。

---

在遥远的过去(在我开始为CodeGear工作之前)，我放弃了IDE所提供的奇特的Delphi式IDL语言，而是编写了自己的IDL并使用MS Midl对其进行了编译。这在很大程度上起作用； IIRC唯一的问题是确保属性获取器和设置器的自动化接口(dispinterfaces)上的dispid(id属性)正确无误-tlibimp预期会有一些不变，但midl不能保证。

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

---

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

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

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

---

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

图书馆供应商发布受支持的版本后，我们将迁移gui应用程序。

---

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

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

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

这已经为我们服务了很多年，对于我们而言，要移交给新的Delphi 2009 IDL / TLB工具集，不仅必须集成到IDE中，而且在自动构建等方面也必须具有通用性。迫不及待地想尝试一下我的手！

---