2010-03-17 16 views
22

¿OpenSubKey() y otras funciones de registro de Microsoft.Win32 devuelven nulo en sistemas de 64 bits cuando las claves de registro de 32 bits están en Wow6432node en el registro?¿Por qué OpenSubKey() devuelve nulo en mi sistema Windows 7 de 64 bits?

Estoy trabajando en un marco de prueba de unidades que realiza una llamada a OpenSubKey() desde la biblioteca .NET.

Mi sistema de desarrollo es Windows   7 entorno de 64 bits con Visual Studio 2008 SP1 y Windows   7 SDK instalado.

La aplicación que estamos probando unitaria es una aplicación de 32 bits, por lo que el registro se virtualiza bajo HKLM\Software\Wow6432node. Cuando llamamos: se devuelve

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

nulo, sin embargo, que indica explícitamente que mirar aquí funciona:

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

Por lo que entiendo esta función debe ser agnóstico a entornos de 32 bits o de 64 bits y debe saber saltar al nodo virtual.

Aún más extraño es el hecho de que la misma llamada dentro de una versión compilada e instalada de nuestra aplicación funciona perfectamente en el mismo sistema y está obteniendo las claves de registro necesarias para ejecutar; que también se están colocando en HKLM\Software\Wow6432node.

¿Qué debo hacer?

+0

Seguimiento: resultó que no era necesario crear un nuevo objetivo de plataforma después de todo. Ejecutamos las pruebas a través de nunit, que distribuye un ejecutable específico de x86. El uso del ejecutable específico x86 permitió que las pruebas accedieran al Registro sin cambios en el marco. – BrMcMullin

+0

He encontrado la respuesta aquí [http://stackoverflow.com/questions/1074411/how-to-open-a-wow64-registry-key-from-a-64-bit-net-application](http://stackoverflow .com/questions/1074411/how-to-open-a-wow64-registry-key-from-a-64-bit-net-application) – Jirapong

Respuesta

22

Parece que su proyecto de prueba de unidad compila a 64 bit. En la configuración Compile del proyecto de prueba de la unidad, configure la "CPU de destino" en x86 (en lugar de AnyCPU).

+3

¡Ajá! Eso es de hecho lo que estaba sucediendo. ¡Muchas gracias! – BrMcMullin

3

Sí, también tengo el mismo problema con Windows 7 de 64 bits y Visual   Studio   2008 SP1. Pero mi solución es lo contrario, que es cambiar de "x86" a "Cualquier CPU" o "x64".

+0

Eso también funcionará, pero para mi caso necesitaba soporte de 32 bits para nuestro entorno de automatización – BrMcMullin

7

Si realmente necesita una aplicación de 32 bits, puede acceder al registro de 64 bits como esto:

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

¿Cuál es la versión mínima requerida de .NET para OpenBaseKey() para estar disponible? En particular, ¿estaría disponible con Visual Studio 2008? –

+0

.NET 4.0 o posterior? –

+0

Parece ser .NET 4.0. De [otra respuesta] (http://stackoverflow.com/questions/26217199/what-are-some-alternatives-to-registrykey-openbasekey-in-net-3-5/26217602#26217602): "Para las versiones .NET antes que la versión 4, no hay una API de marco que permita el acceso a vistas de registro alternativas ". –

0

A quién puede afectar

En mi prueba, si está utilizando Cualquier CPU para construir el código para hacer OpenSubKey y ejecutarlo en un sistema operativo x64. Descubrirá que no está trabajando donde espera.

decir, por ejemplo: (Probado en .NET 4.5.2)

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

Al revisar la rsk.GetSubKeyNames()

que marcó esta en depuración , el resultado no es ni HKLM ni HKCU, al menos no puedo decir qué es (muy parecido a HKCU pero no es lo mismo).

Y el más famoso problema que esto podría conducir a es:

DeleteSubKeyTree tirará Excepción argumento. si intenta abrir la subclave antes de eliminar, está bien, pero al hacer la eliminación, dirá, oye, no está aquí ...

Tenga cuidado, ahora nunca más usaré AnyCPU .

Cuestiones relacionadas