CODEWITHSUNDEEP
c#windowsregistry
Willy
Willy

Reputation: 10650

Getting registry key returns null when using Registry.LocalMachine.OpenSubKey and the key exists

I am trying to get below registry key from Windows Registry:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\16.0\ClickToRunStore\Applications

and then the value for Outlook.

I am running on a Windows 64 bits and Outlook is installed in 64 bits

Using below piece of code is working:

RegistryKey lmRegistry
= RegistryKey.OpenBaseKey(RegistryHive.LocalMachine,
                          Environment.Is64BitOperatingSystem
                              ? RegistryView.Registry64
                              : RegistryView.Registry32);

string keyPath = @"SOFTWARE\Microsoft\Office\16.0\ClickToRunStore\Applications";
RegistryKey registry = lmRegistry.OpenSubKey(keyPath);

string  keyName = "Outlook";
string value = registry.GetValue(keyName) as string;

However if I do below it does not work, rk is null:

using (RegistryKey rk = Registry.LocalMachine.OpenSubKey(keyPath))
{
    string outlookPath = rk?.GetValue(keyName) as string;
}

I am trying to understand why I am getting null in the second case since keyPath and keyName exist both in the registry.

Why is it necessary to first select the correct registry view using RegistryView if I am already pointing to the full and correct keyPath?

For example If I had installed Outlook 32 bits installed on Windows 64 bits instead of Outlook 64 bits, wouldn't it be enough to retrieve it using OpenSubkey and then GetValue without previously using OpenBaseKey if for example I specify the full path as "SOFTWARE\WOW6432Node\Microsoft\Office\16.0\ClickToRunStore\Applications" ? Why do I have to use OpenBaseKey first?

Upvotes: 0

Views: 776

Answers (1)

lee
lee

Reputation: 21

I just walked a coworker through this same scenario. To fix using the shorter code snippet, set the target architecture of your project to x64 to force your process to run as 64-bit. Assemblies compiled with x86 or AnyCPU run as a 32-bit process.

The reason for the apparent weirdness is because the registry redirector presents a different logical view of the registry to 32-bit processes running on a 64-bit version of Windows. The longer code snippet explicitly forces the logical view to the one you want no matter which target architecture you compile with.

Upvotes: 2

Related Questions