.net 为什么 OpenSubKey() 在我的 Windows 7 64 位系统上返回 null？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2464358/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why is OpenSubKey() returning null on my Windows 7 64-bit system?
提问by BrMcMullin
Do OpenSubKey() and other Microsoft.Win32 registry functions return null on 64-bit systems when 32-bit registry keys are under Wow6432node in the registry?
当 32 位注册表项在注册表中的 Wow6432node 下时，OpenSubKey() 和其他 Microsoft.Win32 注册表函数是否在 64 位系统上返回 null？
I'm working on a unit testing framework that makes a call to OpenSubKey() from the .NET library.
我正在开发一个单元测试框架，它从 .NET 库中调用 OpenSubKey()。
My development system is a Windows 7 64-bit environment with Visual Studio 2008SP1 and the Windows 7 SDK installed.
我的开发系统是 Windows 7 64 位环境，安装了Visual Studio 2008SP1 和 Windows 7 SDK。
The application we're unit testing is a 32-bit application, so the registry is virtualized under HKLM\Software\Wow6432node. When we call:
我们正在单元测试的应用程序是一个 32 位应用程序，因此注册表在HKLM\Software\Wow6432node. 当我们调用：
Registry.LocalMachine.OpenSubKey( @"Software\MyCompany\MyApp\" );
Null is returned, however explicitly stating to look here works:
返回 Null，但明确说明查看此处有效：
Registry.LocalMachine.OpenSubKey( @"Software\Wow6432node\MyCompany\MyApp\" );
From what I understand this function should be agnostic to 32-bit or 64-bit environments and should know to jump to the virtual node.
据我了解，此功能应该与 32 位或 64 位环境无关，并且应该知道跳转到虚拟节点。
Even stranger is the fact that the exact same call inside a compiled and installed version of our application is running just fine on the same system and is getting the registry keys necessary to run; which are also being placed in HKLM\Software\Wow6432node.
更奇怪的是，在我们的应用程序的编译和安装版本中，完全相同的调用在同一系统上运行得很好，并且正在获取运行所需的注册表项；也被放置在HKLM\Software\Wow6432node.
What should I do?
我该怎么办？
采纳答案by Heinzi
It sounds like your unit testing projectcompiles to 64 bit. In the Compilesettings of your unit testing project, set the "Target CPU" to x86(instead of AnyCPU).
听起来您的单元测试项目编译为 64 位。在Compile单元测试项目的设置中，将“目标 CPU”设置为x86（而不是AnyCPU）。
回答by nmat
If you really need a 32 bit application, you can access the 64 bit registry like this:
如果你真的需要一个 32 位应用程序，你可以像这样访问 64 位注册表：
RegistryKey localMachine64 = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64);
RegistryKey regKey = localMachine64.OpenSubKey(@"Software\MyCompany\MyApp\", false);
回答by Rudi Suwanto
Yes, I also have the same issue with Windows 7 64-bit and Visual Studio 2008 SP1. But my solution is the opposite, which is to change from "x86" to either "Any CPU" or "x64".
是的，我在 Windows 7 64 位和 Visual Studio 2008 SP1 上也有同样的问题。但我的解决方案是相反的，即从“x86”更改为“Any CPU”或“x64”。
回答by Jcat
To whom may concern
谁可能关心
In my test, if you are using AnyCpu to build the code to do the OpenSubKey, and run it on a x64 OS, You will find that you are not working on where you are expecting.
在我的测试中，如果您使用 AnyCpu 构建代码来执行 OpenSubKey，并在 x64 操作系统上运行它，您会发现您没有在预期的地方工作。
Say for example: (Tested in .net 4.5.2)
例如说：（在 .net 4.5.2 中测试）
RegistryKey rsk = Registry.LocalMachine.OpenSubKey("SOFTWARE");
when you check the rsk.GetSubKeyNames()
当您检查 rsk.GetSubKeyNames()
I checked this in debug , the result is neither HKLM nor HKCU, at least i cannot tell what it is (very much like HKCU but not the same).
我在调试中检查了这个，结果既不是 HKLM 也不是 HKCU，至少我不知道它是什么（非常像 HKCU 但不一样）。
And the most famous issue this could lead to is:
这可能导致的最著名的问题是：
DeleteSubKeyTree will throw Argument Exception. if you try open the subkey before deleting, it is ok, but when doing the deletion, it will say, hey, it is not here...
DeleteSubKeyTree 将抛出参数异常。如果你在删除之前尝试打开子项，可以，但是在删除时，它会说，嘿，它不在这里......
So be careful, now I will never never use AnyCPU any more.
所以要小心，现在我再也不会使用 AnyCPU 了。
