Delphi和COM：TLB和维护问题

Question

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

• 在Delphi和/或COM中经验丰富的人，您是否有任何工作场所可以使用错误的TLB界面？ 一些错误是：IDE在大型TLB的编辑过程中崩溃，方法ID丢失，TLB损坏等。 在这里，我们还没有找到任何好的解决方案。实际上我们尝试升级做新的2007版本。但是新的IDE TLB接口具有我们之前发现的相同错误。

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

我们刚刚安装了Delphi 2009，它似乎确实改进了对Typelibraries的支持。然而，我已经与COM和类型库合作了很长一段时间，这是我多年来发现的一般陷阱。我同意它很漂亮，并且一直到Delphi 2006（我们使用2009之前的版本）。

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

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

Answer 4

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

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

Answer 5

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

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

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

这已经很好地服务了我们多年，而且对于我们来说，移动新的Delphi 2009 IDL / TLB工具集不仅要集成到IDE中，还要在自动构建等方面具有多种功能。迫不及待地想通过一些实验弄脏我的手！