Wix Toolset配置文件关联时HKMU与HKCR注册表行为及RegistryRootType疑问

问题场景 #

使用Wix Toolset实现文件关联功能时，基础配置代码如下：

<RegistryValue Root="HKMU"
Key="SOFTWARE\Classes\.myfile" Value="myfile" Type="string"/>
<RegistryValue Root="HKMU"
Key="SOFTWARE\Classes\myfile" Value="MyFileTypeInWindowsExplorer" Type="string"/>

配置过程中遇到两个核心疑问：

• 分别使用HKMU与HKCR作为注册表根时，文件关联均可正常运行，但按照常规认知应当优先使用HKCR。观察到其他开发者用HKMU配置时，注册表项会直接写入CLASSES_ROOT路径，即使安装包不是仅针对当前用户的安装场景，也没有按预期写入CURRENT_USER路径，这一行为的逻辑是什么？
• 使用对应CLASSES_ROOT的HKCR配置时，在注册表编辑器中无法查看到对应配置项，但关联功能实际可正常生效，是否说明配置项真实存在但对当前查看的用户不可见？

各RegistryRootType的实际运行逻辑 #

Wix中的注册表根并非完全对应固定的物理注册表路径，部分根内置了Windows Installer层面的自动重定向逻辑，常见可选值的行为如下：

• HKCR：对应Windows Installer封装的HKEY_CLASSES_ROOT虚拟操作入口，并非直接指向某一个固定的物理路径。
  • Windows系统本身的HKEY_CLASSES_ROOT就是合并视图：会把HKLM\SOFTWARE\Classes（全机器生效配置）和HKCU\SOFTWARE\Classes（仅当前用户生效配置）合并展示，同路径下用户级配置会优先覆盖机器级配置。
  • Wix的HKCR根会由Windows Installer根据安装包的部署范围自动选择写入路径：全机器安装（ALLUSERS=1）时，配置项写入HKLM\SOFTWARE\Classes；仅当前用户安装（ALLUSERS=""）时，配置项写入HKCU\SOFTWARE\Classes。
  • 注册表编辑器中找不到配置项的常见原因：全机器安装时，当前查看注册表的账户没有管理员权限，无法读取HKLM下的对应项；或是手动查看单独的HKCU\SOFTWARE\Classes路径，自然找不到实际写到HKLM下的配置，但系统合并的CLASSES_ROOT视图可正常识别配置，因此文件关联能正常生效。
• HKMU：全称是HKEY_Machine or User Classes，是Wix专门为文件关联场景设计的特殊注册表根，核心逻辑是自动匹配对应部署范围的Classes配置路径：
  • 安装包为全机器部署时，写入位置和HKCR完全一致，即HKLM\SOFTWARE\Classes；
  • 安装包为仅当前用户部署时，写入位置为HKCU\SOFTWARE\Classes；
  • 之所以会产生“本该写入CURRENT_USER却写入了CLASSES_ROOT”的误解，是因为HKMU从设计上就不是HKCU的别名，它的作用就是帮开发者自动适配不同安装范围下的文件关联路径，不需要手动根据部署模式切换注册表根，全机器安装时自然会写入对应机器级的CLASSES_ROOT路径。
• 其余常用注册表根的固定行为（无自动重定向）：
  • HKLM：直接映射物理路径HKEY_LOCAL_MACHINE
  • HKCU：直接映射物理路径HKEY_CURRENT_USER
  • HKU：直接映射物理路径HKEY_USERS

配置建议 #

• 实现文件关联这类需要同时兼容全机器、当前用户两种安装模式的配置时，优先使用HKMU，不需要手动判断部署范围，可避免因权限不足导致的注册表写入失败；
• 明确安装包为固定全机器部署时，使用HKCR和HKMU的效果完全一致；
• 不要将HKMU作为HKCU的别名用于普通注册表写入场景，它仅适配Classes相关路径的自动选择逻辑。

内容的提问来源于stack exchange，提问作者Sonnich Jensen