.net 为什么在我的Windows 7 64位系统上OpenSubKey（）返回null？

当32位注册表项位于注册表中的WOW6432节点下时，64位系统上的OpenSubKey（）和其他Microsoft.Win32注册表函数是否返回null

我正在开发一个单元测试框架，该框架从.NET库调用OpenSubKey（）

我的开发系统是一个安装了SP1和Windows7 SDK的Windows7 64位环境

我们正在进行单元测试的应用程序是一个32位应用程序，因此注册表是在

HKLM\Software\Wow6432node

下虚拟化的。当我们打电话时：

Registry.LocalMachine.OpenSubKey( @"Software\MyCompany\MyApp\" );

返回Null，但明确声明在此处查找有效：

Registry.LocalMachine.OpenSubKey( @"Software\Wow6432node\MyCompany\MyApp\" );

据我所知，该函数对32位或64位环境不可知，并且应该知道如何跳转到虚拟节点

更奇怪的是，我们的应用程序的编译和安装版本中完全相同的调用在同一个系统上运行得很好，并且获得了运行所需的注册表项；它们也被放置在

HKLM\Software\Wow6432node

中

---

我该怎么办？

听起来您的单元测试项目编译为64位。在单元测试项目的

Compile

设置中，将“目标CPU”设置为

x86

（而不是

AnyCPU

）。

是的，Windows 7 64位和VisualStudio2008 SP1也存在同样的问题。但我的解决方案正好相反，即从“x86”更改为“任意CPU”或“x64”。

如果您确实需要32位应用程序，您可以像这样访问64位注册表：

RegistryKey localMachine64 = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64);
RegistryKey regKey = localMachine64.OpenSubKey(@"Software\MyCompany\MyApp\", false);

可能与谁有关

在我的测试中，如果您使用AnyCpu构建代码来执行OpenSubKey，并在x64操作系统上运行它，您将发现您并没有按照预期的方式工作

例如：（在.net 4.5.2中测试）

当您检查rsk.GetSubKeyNames（）时

我在调试中检查了这个 ，结果既不是HKLM也不是HKCU，至少我说不出它是什么（非常像HKCU，但不一样）

这可能导致的最著名的问题是：

DeleteSubKeyTree将引发参数异常。 如果您在删除之前尝试打开子项，这是可以的，但是在执行删除操作时，它会说，嘿，它不在这里

---

所以要小心，现在我再也不会使用任何CPU了。

Aha！这确实是正在发生的事情。非常感谢你！这确实也会起作用，但就我的情况而言，我需要32位对自动化环境的支持。我在下面找到了答案：事实证明，我们根本不需要创建新的平台目标。我们通过nunit运行测试，nunit分发一个x86特定的可执行文件。使用x86特定的可执行文件允许测试在不更改框架的情况下访问注册表。要获得OpenBaseKey（）所需的最低.NET版本是多少？特别是，是否可以使用VisualStudio2008？它似乎是.NET4.0。From：“对于版本4之前的.NET版本，没有允许访问备用注册表视图的框架API。”。

RegistryKey rsk = Registry.LocalMachine.OpenSubKey("SOFTWARE");