windows-7 - 我可以阻止 VB6 OCX 控件在编译时生成 OCA 注册表项吗？

Question

我们这里有一个用 VB6 编写的项目(是的，我知道...)，它使用一些同样用 VB6 编写的 ActiveX 对象(OCX 文件)。

最近我们开始为这个项目使用构建服务器，并且在 MSBuild Extension Pack 的帮助下我们设计了一个构建过程，以正确的顺序编译库、控件和可执行文件，适本地注册它们，然后注销所有内容，以便为下一次运行留下干净的机器。

问题是每次编译运行都会在注册表中留下 VB6 编译器似乎需要的扩展类型库/对象缓存文件的条目，并且当控件未注册时，这些条目不会被删除.

即对于每个具有指向 OCX 的 CLSID 条目的已注册组件，在我们使用 VB6 编译项目后，存在一个新生成的 OCA CLSID。

因为我们在每次构建后取消注册 OCX 控件并且每次都重新生成 OCA CLSID，所以 OCA 条目的数量继续增长。

有谁知道是什么导致了这些条目，我们是否可以通过某种注销流程删除它们，或者我们是否可以首先阻止它们的创建？

一些注意事项:

• 构建机器是Windows 7
• 已启用二进制兼容性，因此 OCX 控件的 CLSID 不会更改。
• Reg-Free COM 目前不是一个选项
• 我们不能简单地注册控件并留下它们，因为我们想要运行该项目的多个构建。

Answer 1

关键是停止尝试将 DLL(包括 OCX)视为静态链接库。您的构建过程不合适。

虽然 VB6 支持粗略的“项目组”功能，但这仅适用于小规模的非结构化开发工作，例如不为人知的业务部门编码员使用的那些工作。

而是努力在您的 EXE 项目中保持以应用程序为中心的逻辑。将长期可重用逻辑分解到 DLL 和 OCX 项目中，您将它们视为独立、独特的内部产品。将这些(包括源代码控制)与使用应用程序完全分开。

通常它们应该比应用程序代码稳定得多，在应用程序代码中，更改是由它们包含的业务逻辑更频繁地驱动的。

即使其中一些必须包含业务逻辑，您仍然希望将它们视为单独的软件实体。尽量使它们与具有更高稳定性的库区分开来。

这比单一的“Bable 之塔”开发需要更多的纪律，但也有很多返回。一方面，构建时间更快。作为奖励，几乎所有这些与源代码控制相关的问题对于具有更高修补和摆弄率的应用程序都消失了。