Mik*_*sen 3 vb6 regsvr32 dcom com+ clireg32
我们有一个遗留的 VB6 应用程序，它在启动时通过拉取最新文件并注册 COM 组件来更新自身。这适用于在另一台计算机上的 COM+ 中注册的本地 (regsvr32) ActiveX COM 组件和远程 (clireg32) ActiveX COM 组件。
出于安全原因，新要求阻止我们写入 HKEY_LOCAL_MACHINE (HKLM)，这显然是调用 regsvr32 和 clireg32 时默认发生的情况。
我们提出了一种使用RegOverridePredefKey Windows API 方法在 HKEY_CURRENT_USER\Software\Classes (HKCU) 下注册本地 COM 组件的方法。这是通过将注册表中的插入重定向到 HKCU 位置来实现的。然后，当COM组件被实例化时，Windows首先查找HKCU，然后再在HKLM中查找组件信息。这取代了 regsvr32 正在做的事情。
我们此时遇到的问题是，当我们尝试使用clireg32注册VBR/TLB时，此注册过程还将注册键添加到HKEY_LOACL_MACHINE中。
有没有办法重定向 clireg32.exe 以注册组件为 HKEY_CURRENT_USER？是否有任何其他方法允许我们在安全访问受限的客户端计算机上注册这些 COM+ 组件？
目前我们唯一的解决方案是手动将注册信息写入注册表，但这并不理想，并且会成为一个维护问题。
我在这里看到很少有令人满意的答案。使用 12 年历史技术的应用程序需要安装更新的想法很奇怪，而且在现代机器上得不到很好的支持。我认为像免注册 COM 这样的常见解决方案与 COM+ 不兼容。同样很奇怪的是，错误修复风格的更新需要重新注册组件。您是否已验证这确实是必需的？
延伸到这个主题，您在部署中实际更改 GUID 的频率是多少？当密钥不经常更改时，您自己负责注册而不是让组件自己负责注册应该是可行的。就像使用 SysInternals 的 ProcMon 实用程序捕获注册一样简单，编写一个设置 HKCU 密钥的 .reg 文件。
除此之外，您确实需要获得不可写注册表项的权限。如果您无法获得客户的同意，请考虑请求安装更新的计划任务。只要系统管理员允许，他们就可以获得访问权限。