这意味着原始开发人员可能没有正确设置“二进制兼容性”。这意味着 VB6 dll 每次构建时都会获得一个“新的 com guid”。这意味着您最初的 VB6 开发人员可能是一群黑客。
您可以在此处阅读有关二进制兼容性的部分。
http://support.microsoft.com/kb/161137
坐上时光机，然后回去打那个说“我们现在不需要解决二进制兼容性问题的人，我们只需注销并重新注册组件……Easy Peezey！” ......
如果我错了，请告诉我。但每次我看到“取消注册 com”和“重新注册 com”......它都回到了那个聪明的决定。
这是一个更长的讨论：
编辑：
如果 ocx 没有改变........那么你应该只需要在构建机器上注册一次。
听起来这些人只是在处理这些 OCX 的客户端，而不是自己修改和重新编译 OCX。
如果是这样，您应该像管理 VB6 开发系统本身一样管理这些库的安装。这意味着每个工作站都需要安装一次您正在使用的控制套件（好吧，并在新版本投入使用时进行维护）。开发人员库的安装程序会部署 .DEP 文件以及设计时许可证密钥注册表项等内容，因此无论如何不应将使用 regsvr32 视为可行的策略。
如果您正确设置开发人员工作站并对其进行维护，则没有任何理由注册和取消注册这些东西。
直接的答案是否定的，如果没有注册这些依赖项，就无法编译具有 OCX 依赖项的 VB6 项目。
此外，编译行为本身涉及 VB6 尝试注册它刚刚构建的内容（除非您正在编译为 EXE）。这通常需要 VB6 IDE 和/或其编译器以“管理员”权限运行。因此，无论如何，权限都是一个难以避免的问题。
我相信这些问题可能会因为 VB6 本身（IDE 和/或运行时）有时会尝试为您自动注册某些内容而被混淆，但这样做时会保持沉默。
您可能应该创建一个与您在部署中使用的构建过程不同的过程来设置开发 PC。这可能会“感觉”错误，尤其是如果您有其他编程环境的经验，但我要强调的是，使用 VB6 可能会非常痛苦和有问题，因此实用主义通常是正确的。
在开发 PC 上：设置所有不变的依赖项一次（并记录它们），然后不理会它们（如另一个答案中所述。）当出现奇怪的依赖项问题时，请在执行任何其他操作之前验证 PC 设置是否正确。
如果您拥有依赖项的所有源代码，那么我会考虑您是否可以在 VB6 项目组 (VBG) 中真正运行它们，而根本不编译它们。（VBG 类似于 .NET 解决方案，但功能远没有那么强大。）我经常这样做，这样可以减少很多浪费的时间。开发人员不一定需要编译为 EXE / DLL / OCX 的代码 - 他们通常只需要能够在 IDE 中运行它。
在构建 PC 上：如果您始终可以从干净的环境开始，例如在虚拟机中，那么我认为以自动化方式从头开始注册所有内容实际上是一个好主意，因为这有助于验证没有丢失或不匹配的内容。当源代码管理中的某些依赖项已更改但仍存在于构建机器上时，不这样做就重新使用相同的构建环境可能会掩盖问题。在 VM 上，权限通常不是限制因素。
笔记：
据我所知，如果您正在构建 EXE，VB6 不需要任何提升的权限。
在 VB6 IDE 中运行代码也不行。
[警告 1]：
从技术上讲，可以为 VB6.exe 本身创建一个并行应用程序清单文件，并在该清单中包含您需要的任何依赖项，从而避免必须注册它们。
但这将远远超出使用 VB6 工具的正常方式——它是一种 hack——并且可能不值得付出潜在的巨大努力。我认为我从未见过有效的示例，因此我不建议将其作为实用的解决方案，但为了完整性而提及它。
也许在某些锁定的企业 IT 场景中，这可能会带来回报……也许。在那种情况下，在 VM 中进行开发工作可能是一个更好的选择。