为什么 OpenSubKey() 在我的 Windows 7 64 位系统上返回 null? [英] Why is OpenSubKey() returning null on my Windows 7 64-bit system?

问题描述

当 32 位注册表项在注册表中的 Wow6432node 下时，OpenSubKey() 和其他 Microsoft.Win32 注册表函数是否会在 64 位系统上返回 null?

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?

我正在开发一个从 .NET 库调用 OpenSubKey() 的单元测试框架.

I'm working on a unit testing framework that makes a call to OpenSubKey() from the .NET library.

我的开发系统是 Windows 7 64 位环境，带有 Visual Studio 2008 已安装 SP1 和 Windows 7 SDK.

My development system is a Windows 7 64-bit environment with Visual Studio 2008 SP1 and the Windows 7 SDK installed.

我们正在单元测试的应用程序是 32 位应用程序，因此注册表在 HKLMSoftwareWow6432node 下虚拟化.当我们打电话时:

The application we're unit testing is a 32-bit application, so the registry is virtualized under HKLMSoftwareWow6432node. When we call:

Registry.LocalMachine.OpenSubKey( @"SoftwareMyCompanyMyApp" );

Null 被返回，但明确说明在此处查看有效:

Null is returned, however explicitly stating to look here works:

Registry.LocalMachine.OpenSubKey( @"SoftwareWow6432nodeMyCompanyMyApp" );

据我所知，这个函数应该与 32 位或 64 位环境无关，并且应该知道跳转到虚拟节点.

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.

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

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 HKLMSoftwareWow6432node.

我该怎么办?

推荐答案

听起来您的单元测试项目编译为 64 位.在单元测试项目的Compile设置中，将Target CPU"设置为x86(而不是AnyCPU).

It sounds like your unit testing project compiles to 64 bit. In the Compile settings of your unit testing project, set the "Target CPU" to x86 (instead of AnyCPU).

这篇关于为什么 OpenSubKey() 在我的 Windows 7 64 位系统上返回 null?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！