ActivationRegistrationManager Machine Wide

[DominicMaas]

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.

[DrusTheAxe]

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]

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.

[mominshaikhdevs]

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.

just like others have pushed MSIX to the limit.
see:

• [MSIX] Provide Public API for launching App Execution Aliases over both WinRM and SSH. #5258 (comment)
  for a comprehensive list of MSIX Limitations/Bugs.

[DrusTheAxe]

having to do some pretty hacky things to work around it

Could you elaborate?

[DominicMaas]

So essentially, we're an app store of sorts.

• Setting path variables for installing an SDK for partner applications (cannot be cleaned up after install)
• Creating folders outside of package virtualization in %appdata% as other apps need to read/write to these folders (cannot be cleaned up)
• Installing an authorization service which needs to run independently from the app and system wide (cannot be installed with the app inside the appxmanifest, so is installed using our installer exe). Having to do some checks on service startup to uninstall itself when the package is detected as uninstalled. This also writes to %ProgramData%

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.