Answered by:

How can a Windows Store app read from and write to the registry?

Question

I am trying to create a solution for the basic scenario, where a Windows Store app can access (read/write) values from the system registry (HKLM) and provide this as a means/API for other Windows Store apps to read/write these values. I have already read
through most of the available documentation and am already aware of the Windows Store apps' system access and design issues.

However, I am trying to see if there are any other components I can create as a chain so that my app, using these external components, can read/write registry values.
Unfortunately, there is no way to get rid of the local registry value mechanism or replace it with something else. So I must find a solution within these constraints.

Here are some of the options I could come up with and related questions. I want to understand what would be possible:

create a WinRT component dll (c++) and use the component dll to access the registry: unfortunately, the RegKeyXXX functions seem to be disabled for WinRT components through windows.h (via regions), whereas HKEY is not. Is there a different API that
I can use or is there no way for a winRT component to access the registry directly?

create a regular COM dll that does the registry access and then try to access this COM object either through the Windows Store app (although CoCreateInstanceFromApp won't work and CoCreateInstance needs a reg-free COM dll (?) )

Create a local service process (COM) - for registry access- and somehow connect to this service from either the Windows Store App or RT component

Create a static RT library and move the registry access code there: the registry access APIs again seem to be unavailable

Create a static RT library and call the regular COM object from there: it has the same problem with CoCreateInstance

Answers

If the only possible solution involves registry access then you will need to write your app as a desktop app, not a Windows Store app. Windows Store apps can neither access the registry directly nor communicate directly with other apps. None of the mechanisms
you mention are available to Windows Store apps.

All components, DLLs, and libraries used by a Windows Store app have the same API restrictions of the main Windows Store app. While you can bypass the compile time checks, the app will not pass certification and will not have sufficient permissions to access
the registry at runtime (the calls will fail with Access Denied errors). For Viceman's suggestion: requiring a desktop component will prevent the app from being certified, and Windows Store apps do not have permission to make network connections
back to the local machine. This can be disabled for debugging purposes, but not for production.

If you can let us know what scenario you are trying to achieve that requires registry access we may be able to either find another way or confirm that it must be done from a desktop apps.

If the only possible solution involves registry access then you will need to write your app as a desktop app, not a Windows Store app. Windows Store apps can neither access the registry directly nor communicate directly with other apps. None of the mechanisms
you mention are available to Windows Store apps.

All components, DLLs, and libraries used by a Windows Store app have the same API restrictions of the main Windows Store app. While you can bypass the compile time checks, the app will not pass certification and will not have sufficient permissions to access
the registry at runtime (the calls will fail with Access Denied errors). For Viceman's suggestion: requiring a desktop component will prevent the app from being certified, and Windows Store apps do not have permission to make network connections
back to the local machine. This can be disabled for debugging purposes, but not for production.

If you can let us know what scenario you are trying to achieve that requires registry access we may be able to either find another way or confirm that it must be done from a desktop apps.

You pretty much confirmed my fears and I was hoping to see if I missed anything after a couple weeks of investigation. I'd already dismissed the localhost connection option (or any other related service/client option).

Our main scenario is to provide a common API mechanism to keep a Windows Store app, a desktop managed app and a win32 native app in sync for a set of parameter values. Our legacy solution, that was designed pre-Windows 8, provided this support for desktop
apps and win32 native apps via the system registry. Now we are trying to extend the support to Windows Store apps, but we cannot change the registry solution for the current version, which would break existing apps.

We are also trying to create a solution for a new version and understand if there is another synchronization mechanism in Windows 8 we can use to synchronize these 3 separate application types on a single machine.

This is a completely local machine situation, where the parameter values we need to synchronize between the apps/technologies are local machine settings, so a web service - when the data goes out of the machine is not acceptable, and because of the restrictions
on connecting to the localhost, I don't think a local web service is going to work.

The Windows Store app(s) also has to go through the Windows Store as a typical consumer solution.