Andreas
Andreas

Reputation: 992

Registry OpenSubkey returns null, although it is there

I have read almost all the other questions to this topic, but they usually resolved by using the wrong architecture view in the registry.

I am trying to open a subkey in "...\Outlook\Addins". I have the subkey available for both architectures ( "HKLM\Software... " and "HKLM\Software\Wow3264Node..." ). But I know through testing, that the code is looking under "WOW6432Node".

So here is the code snippet.

var hklm = RegistryKey.OpenBaseKey RegistryHive.LocalMachine,RegistryView.Default);
var reg = hklm.OpenSubKey(@"Software\Microsoft\Office\Outlook\Addins\MyAddin", false);

I also tried

var hklm = RegistryKey.OpenBaseKey RegistryHive.LocalMachine,RegistryView.Registry32);
var hklm = RegistryKey.OpenBaseKey RegistryHive.LocalMachine,RegistryView.Registry64);

to debug it and looked for the subkeys, that are visible, which give me all other entries (even newly created ones), but not the one I am looking for.

I also checked Registry Permissions, which are the same as for the others I can see.

So why do I receive always null for "reg"?

Edit: Maybe I should add, that I am looking for that key from inside the addin. When trying it from a short test console application, I see the subkey when calling

reg.GetSubKeyNames();

Upvotes: 1

Views: 2386

Answers (3)

torpid prey
torpid prey

Reputation: 242

This was doing my head in for about 4 hours until I realised I had forgotten to uncheck "Prefer 32-bit" under Project > Software Properties...

Upvotes: 1

Andreas
Andreas

Reputation: 992

As it seems, this is a security "feature". There is no way of accessing the registry branch of the addin, which is looking for it. The information, which I would like to have stored there, needed to be stored somewhere else.

Upvotes: 0

Gerald Versluis
Gerald Versluis

Reputation: 34083

Try changing this

var hklm = RegistryKey.OpenBaseKey RegistryHive.LocalMachine,RegistryView.Default);

to this

var hklm = RegistryKey.OpenBaseKey RegistryHive.LocalMachine,RegistryView.Registry64);

When you run a 32-bits application on a 64-bits OS it tries to find the Wow6432Node automatically. Another way around it probably is to compile it for the x64 architecture.

More info on the RegistryView enumeration can be found on MSDN. Note this line;

If you request a 64-bit view on a 32-bit operating system, the returned keys will be in the 32-bit view.

So you should be safe always requesting the 64-bits keys.

Upvotes: 2

Related Questions