Just as There is no Install – it’s ‘Stage’ and ‘Register’ explained that Install is not truly an installation operation in MSIX, Remove is similarly not an uninstall operation.
This can be surprising – sometimes even alarming – to developers coming from traditional installer technologies such as MSI, where uninstalling software typically implies:
- binaries are deleted
- directories are removed
- registry entries are cleaned
- runtime artifacts are purged
In MSIX, that model simply does not exist.
Remove = Deregister + (Maybe) Destage
From MSIX Deployment’s perspective, a package lifecycle consists of four fundamental operations:
- Stage – acquire and securely place the payload on disk
- Register – associate the package with a user
- Deregister – remove the package association for a user
- Destage – remove the package payload from disk
There’s a symmetry here. Stage and Register do the work necessary to make a package available for use. Deregister and Destage unwind that work, first removing the package from use and ultimately removing it from the system.
Interestingly, the deployment API doesn’t provide DeregisterPackageAsync() or DestagePackageAsync(). Instead, there is only RemovePackage*Async()1.
“Remove” is the public abstraction over unwinding a package’s lifecycle, as far as the system can safely go.
There is no ForceTargetApplicationShutdown option for Remove*() APIs. Instead, remove operations effectively behave as though the option existed and is always enabled. Running processes using the package may be shut down or terminated so the servicing operation can proceed.
If the package is no longer in use, Deployment deregisters it and, when appropriate, destages it.
When appropriate.
Deregistration Is Guaranteed, Destaging Is Conditional
A package removal operation does not necessarily delete the package payload from disk.
Instead, the operation primarily focuses on removing the package’s registrations and system integrations:
- removing user-specific registrations
- disconnecting Start Menu entries
- revoking file type associations
- updating runtime metadata
- releasing MSIX-managed application data
- deleting an internal reference to the package
- destaging the package IF no remaining references exist
From the user’s perspective, the application is gone.
From the operating system’s perspective, however, the package may still be present on disk—available for, and possibly in use by, other users.
That distinction is crucial to understanding why Remove is not the same thing as Uninstall.
Remove always unwinds registrations. Deletion of the package payload is conditional.
But if we’ve just deregistered the package, what references are left?
As it turns out, quite a few.
That’s a tale for Part 2…
1 Remove comes in several variants, including PackageManager‘s RemovePackageAsync() and PackageDeploymentManager‘s RemovePackageByFamilyNameAsync(). These provide variations of scoping what to remove, but otherwise their functionality is the same.
This begs the question why are users given the option to “Uninstall” when it is actually doing a Remove? Take OneDrive for example. If you try to get rid of it via the Settings app, Start Menu, or Programs and Features the only option you will see is “Uninstall”…. but it doesn’t do an uninstall at all. Sign in with another user and OneDrive will be there! Given the information shared in this blog post it seems that it is actually doing a Remove.
*** Take OneDrive for example
As noted by Flux, that's not packaged.
***why are users given the option to “Uninstall” when it is actually doing a Remove
Because "Uninstall" is the best term for end users. Functionally, "Uninstall" a package does uninstall it, from the user's perspective. The fact some shared bits on disk aren't removed if it's still shared makes it unusual compared to some software, but it's not a unique concept.
***when it is actually doing a Remove
This is a developer* oriented blog, so we discuss how the sausage actually works, involving terms and concepts end users rarely see or even know...
OneDrive isn’t a packaged app and doesn’t use the MSIX app model. Nothing in this blog applies to OneDrive.
Looking forward to part 2.