我们有一个遗留的VB6应用程序，它通过下拉最新文件和注册COM组件在启动时自行更新。这适用于本地（regsvr32）ActiveX COM组件和在另一台机器上的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 +组件？
我们目前唯一的解决方案是手动将注册信息写入注册表，但这不是理想的，而且是一个maint问题。
我在这里看到几个快乐的答案。使用需要安装更新的12年技术的应用程序的概念是奇怪的，并且在现代机器上得不到很好的支持。我认为像reg-free COM这样的常见解决方案与COM +不兼容。错误修复样式更新需要重新注册组件也很奇怪。你确认这实际上是必需的吗？
扩展该主题，您实际更改部署中的GUID的频率是多少？当密钥不经常更改时，自己负责注册而不是将其留给组件本身应该是可行的。可以像使用SysInternals的ProcMon实用程序捕获注册一样简单，编写一个设置HKCU键的.reg文件。
除此之外，您确实需要获得不可写的注册表项的权限。如果您无法从客户那里获得好处，那么请考虑要求安装更新的计划任务。如果系统管理员允许，他们可以访问。