Remove Is Not Uninstall

Just as https://devblogs.microsoft.com/insidemsix/there-is-no-install-its-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()¹.

“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…

¹ 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.