Repository navigation
ActivationRegistrationManager Machine Wide #5345
Description
Looking into the feasibility of making some of the ActivationRegistrationManager register methods work for machine wide installs / installers (such as RegisterForProtocolActivation and RegisterForStartupActivation), possibly by passing an optional parameter (CurrentUser / LocalMachine). Obviously MachineWide would require privileged access to write to HKEY_LOCAL_MACHINE
RegisterForStartupActivation seems fairly simple, a single registry entry in XX\Software\Microsoft\Windows\CurrentVersion\Run.
RegisterForProtocolActivation looks like it's a bit more involved with Assoc registry entries, but I assume these could also be written in HKEY_LOCAL_MACHINE vs HKEY_CURRENT_USER?
Context
Looking at installing a WinUI Unpackaged app machine wide. Would love to call the WinAppSDK APIs during the install / uninstall process vs trying to do this in the current user process (registering is easy, unregistering on uninstall gets tricky).
Alternatively I could simulate what WinAppSDK does (I assume these APIs are pretty stable) and write the code myself in the installer.
Activity
DrusTheAxe commentedon Apr 20, 2025
You can generally accomplish this today, but terminology matters so for clarity I'll be very particular in my language.
MSIX supports per-user behavior, and using packaged goods generally requires the package is registered for the user.
MSIX supports All Users, where a package can be added to the system and made available for all users. This is called provisioning. If you provision a package it's made available to all users by way of registering for EACH user (current and future). In this way you get 'per-machine install' results (every user can use it) but the upsides of the per-user model.
For instance, you can update a provisioned package on a machine and each user switches to it at the next opportunity. This is usually at next use if not currently in use, or at worst case at next user login.
You're NOT required to stop every process for every user using the package before you can update a machine from foo v6 to v7, as you would in classic 'per-machine install' models.
To provision a package you'd usually Stage the package then, if the package family isn't already provisioned, call PackageManager.ProvisionPackagesForAllUsersAsync() to provision it. You can also use DISM to provision packages. This is common in image manipulation scenarios like in enterprises, and how Microsoft creates Windows images with Calculator and Paint provisioned on the image.
Does this accomplish your goals?
DominicMaas commentedon Apr 20, 2025
We're already doing machine wide installs with provisioning and MSIX packages (it's a supported option in our installer), but our certificate has expired, and cannot get a new one with the same subject, so we've lost our package identity (Win11 only work around is no good for us).
With facing the fact that we need to do some migration work anyway to migrate packages, and the fact that there's no guarantee that we can keep getting consistent signing certificate subjects, I'm debating moving off MSIX completely, and looking into that scenario.
We've already pushed MSIX to the limit and are having to do some pretty hacky things to work around it, just makes sense to go fully unpackaged at this point.
DrusTheAxe commentedon Apr 20, 2025
Could you elaborate?
DominicMaas commentedon Apr 20, 2025
So essentially, we're an app store of sorts.
A few other things on top of my head (currently on leave, so can take a deeper look when I'm back at work).
But really this signing limitation is really a dealbreaker. I've been contempt with these work arounds we have going on, even if annoying.
DrusTheAxe commentedon Apr 24, 2025
Does the EnvironmentManager API with its change tracking help with the environment variable issue?
Is the lifetime for these folders tied to the lifetime of the writer package? Or does it need to exist past uninstalling the package?
Is there an Issue about this? (there's a few Issues touching on signing; checking if your concerns are covered by them)
DominicMaas commentedon Apr 28, 2025
Essentially with the serial number being a part of the Subject, we'd have get a new package identity every X years.