Delphi和COM：TLB和维护问题

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

• 在Delphi和/或COM方面有经验的人，您是否有任何关于buggy TLB接口的工作循环？ 其中一些错误是：在编辑大型TLB时IDE崩溃、方法ID丢失、TLB损坏等。 在这里，我们还没有找到任何好的解决方案。实际上我们试着升级了2007年的新版本。但是新的IDE TLB接口具有与我们以前发现的相同的错误

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

---

我想你应该好好看看德尔福2009
Delphi2009对COM支持进行了更改，包括对二进制TLB文件的基于文本的替换
您可以阅读更多信息。
在遥远的过去（在我开始为CodeGear工作之前），我放弃了IDE提供的奇怪的Delphi化IDL语言，编写了自己的IDL并使用MS midl进行编译。这在很大程度上起了作用；唯一需要注意的是IIRC，它确保属性getter和setter的自动化接口（dispinterfaces）上的dispid（id属性）是正确的——tlibimp期望有一些不变量，但midl不能保证

---

然而，现在Delphi 2009使用了一个安全的midl语法子集，并且在盒子中包含了一个用于此midl的编译器并集成到IDE中，这些问题应该是过去的事情了。
我们也刚刚安装了Delphi 2009，它似乎改善了对类型库的支持。然而，我使用COM和类型库已经有相当长的一段时间了，下面是我多年来发现的一些普遍问题。我同意它有相当多的bug，一直到Delphi2006（我们在使用2009之前的版本）
• 在打开之前，始终使每个文件都可写。这听起来很明显，但在使用源代码管理时，有时我们会忘记执行此操作，并在打开文件后尝试删除只读标志-Delphi无法处理此问题。确保tlb在打开之前是可写的
• 如果编辑独立类型库，则必须打开一个项目。由于某些原因，如果单独打开类型库，它将不会保存。创建一个空白项目，然后打开类型库。由于某些原因，这允许保存类型库
• 如果应用程序或COM+使用您的类型库，请确保在打开类型库之前关闭应用程序或禁用COM+。任何打开的应用程序都将阻止保存类型库

---

不过，我认为您最好的解决方案可能是升级。您也可以获得Unicode支持。
这里的TLB接口也有同样的体验：我们只是停止使用它
我们为框架的不同部分使用几个单独的IDL文件（手工构建），利用#include构造将它们包含到实际应用程序的IDL中，然后使用MIDL和tlibimp it生成单个tlb。如果应用程序本身没有IDL，则可以使用不同框架TLB文件的预编译版本
每当框架进入新版本时，都会运行一个脚本，在IDL文件中的所有必要接口上重新生成GUID

---

这已经为我们提供了很多年的良好服务，对于我们来说，在新的Delphi 2009 IDL/TLB工具集上不仅要集成到IDE中，而且在涉及到自动构建和其他方面时还要具有多功能性。迫不及待地想用一些实验来弄脏我的手
使用Delphi 2009极大地减轻了巨大TLB文件的痛苦，并且我们现有对象的转换也很轻松，但是我们的com对象不使用任何第三方库
一旦库供应商发布受支持的版本，我们将迁移gui应用程序