none
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

    Any help is much appreciated...

    Saturday, February 09, 2013 11:38 PM

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.

    --Rob

    Sunday, February 10, 2013 1:33 AM
    Owner

All replies

  • In theory:

    Create a desktop app that read\write registry and translate data to the network.

    In WinStore your app say to user that you need desktop component to install it manual.

    Connect with your desktop app (lets say via IPv4 127.0.0.1).


    • Edited by TheViceMan Saturday, February 09, 2013 11:55 PM
    Saturday, February 09, 2013 11:53 PM
  • In Windows Store Apps, you can not access registry directly. In this case you can use ApplicationDataContainer

    http://msdn.microsoft.com/en-us/library/windows/apps/hh464917.aspx

    http://msdn.microsoft.com/en-us/library/windows/apps/hh465118.aspx

    http://code.msdn.microsoft.com/windowsapps/ApplicationData-sample-fb043eb2

    Sunday, February 10, 2013 1:25 AM
  • 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.

    --Rob

    Sunday, February 10, 2013 1:33 AM
    Owner
  • Hello Rob,

    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. 

    I would really appreciate to hear if you have any suggestions...

    Sunday, February 10, 2013 2:09 AM
  • Is this for an enterprise solution or is it something you plan to deploy via the store?

    The typical recommendation is to synchronize to a web service.

    --Rob

    Sunday, February 10, 2013 3:44 AM
    Owner
  • 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.

    Sunday, February 10, 2013 6:21 AM