Will Apps have direct access to the Registry on Windows Systems

[Daniellled]

Will it be possible for Project Reunion based applications to write to the registry?
I have tested writing to the registry using a MAUI application in .Net 6 Preview 6 and I see nothing being written to the registry. Please see -dotnet/maui#1230

[driver1998]

You can checkout the unvirtualizedResources restricted capability if you really want to, by default the registry access is virtualized.

The unvirtualizedResources restricted capability enables your application to declare the RegistryWriteVirtualization and FileSystemWriteVirtualization elements in its package manifest to disable virtualization for the registry and file system. These declarations prevent the system from virtualizing any writes to HKEY_CURRENT_USER or to the user's AppData folder, respectively. This is useful in scenarios where your application expects other applications to read or write the same registry or file system entries as your application.

https://docs.microsoft.com/en-us/windows/uwp/packaging/app-capability-declarations

[maxkatz6]

Just wonder, is it with fullTrust capability?

[Daniellled]

I think so.

  <Capabilities>
    <rescap:Capability Name="runFullTrust" />
  </Capabilities>

[andreww-msft]

Yes, as maxkatz6 says, this is for packaged Win32 apps, which also need the runFullTrust capability.

[fredemmott]

I think this has changed: with runFullTrust, my HKEY_CURRENT_USER writes seem to be virtualized, and this is as documented at https://docs.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-behind-the-scenes#registry

It's possible to workaround it by following the instructions at https://docs.microsoft.com/en-us/windows/msix/desktop/flexible-virtualization - however, then it must be installed from Powershell with devleoper mode enabled, as AppInstaller refuses to install msix packages with the unvirtualizedResources capability.

Can:

• runFullTrust imply unvirtualized resources? By the user-friendly description, it seems appropriate
• AppInstaller be changed to not ban these?

This makes packaged apps somewhat less attractive when the registry is being used for cross-app settings (including with non-msix apps).

It's also not an effective measure: full trust apps can spawn unsandboxed apps, so I've made a helper app to do my registry writes, and I use CreateProcessW. This works fine - the restriction in app installer just creates extra work.

[fredemmott]

As a concrete example, my app interacts with games using OpenXR, such as Microsoft Flight Simulator. This requires my app to write to HKEY_CURRENT_USER\SOFTWARE\Khronos\OpenXR\1\ApiLayers\Implicit, which is then read by the standard OpenXR initialization process in the games it's interacting with, WMR, SteamVR, Oculus Runtime etc. A virtualized registry write is not readable by the OpenXR loader in other games.

[jonwis]

Packaged Win32 apps ("Desktop Bridge") use the virtualization layer to ensure a clean install & uninstall for customers, so apps don't accidentally leave content behind. Today it's all-or-nothing; you're either packaged and HKU is virtualized, or you're unpackaged and writes "flow through" to the real HKU location.

Unpackaged apps, or those that use sparse-packaging to get identity on their existing installed binaries, don't get registry virtualization.

Ok, so your app needs to tell OpenXR that you exist by writing that key? What data goes in there? Packaged applications live in unpredictable locations - their paths change with every update to your app. So if you're writing a file there and using Package.InstallLocation to tell OpenXR where your binaries live, that might not work.

There's been interest in a "write somewhere outside my container, remove it when I uninstall" feature as a way to improve that.

If this is an extensibility point (that is, letting one app know that another is present) we have other mechanisms for that - like AppExtension - but it requires changes in both the host and the extension.

@dianmsft / @andreww-msft / @dhoehna / @DrusTheAxe - something to add to our backlog.

[fredemmott]

Ok, so your app needs to tell OpenXR that you exist by writing that key?

Yep

• I've found that having other executables load DLLs or read files from my package is unreliable, so I copy them to local app data
• I use SHGetKnownFolderPath(FOLDERID_LocalAppData, KF_FLAG_RETURN_FILTER_REDIRECTION_TARGET, ...) to get the actual path they'll be written
• On every app launch, I set the key, and disable any stale MyApp-OpenXR keys; so moving on upgrade isn't a problem
• Concretely, I currently have C:\Users\Fred\AppData\Local\Packages\FredEmmott.Self.OpenKneeboard_qvw5xrmsm8j1t\LocalCache\Local\OpenKneeboard\Shared\OpenKneeboard-OpenXR.json in the registry
• The registry key is left behind on uninstall. This isn't great, though isn't a major problem: if the openxr extension isn't loadable, openxr will just ignore it. If it is, it does nothing if my app isn't maintaining some named shared memory

[dhoehna]

write somewhere outside my container, remove it when I uninstall

I tried to anticipate this problem when making Environment Manager. Environment Manager uses the registry location HKCU/Software/ChangeTracker to track EV mods. This location is unvirtualized and can be used for other "My app wrote this thing. Please remove it." Namely by using a new Windows App SDK Api so the correct values can be written to the registry.

If there is a pressing need for another "Please track this write" that can be done in Two easy steps

1. Write a new API
2. Write an undocked Deh that reads the registry at uninstall time.

[DrusTheAxe]

@dianmsft / @andreww-msft / @dhoehna / @DrusTheAxe - something to add to our backlog.

Already in the backlog. We've considered multiple solutions ranging from the very targeted "delete this regkey when I'm uninstalled" to the very generic "<Extension Category="windows.uninstallConfigTask"...>". The latter is the most promising as it doesn't suffer complications the more targeted solutions face (often too specific for any generic solution to reliably do the right thing).

I submitted an item about this to ProductBoard but I guess that doesn't show up until it's gone through some kind of review? @AdamBraden would you know?