Uninstall/Reset/Repair Tasks

Proposal: Uninstall/Reset/Repair Tasks

Summary

Provide an uninstall hook for custom activity equivalent to windows.preinstallConfigTask
and windows.updateTask.
Also potentially provide similar support for 'repair' and 'reset' operations.

Microsoft-internal task 34863092

Rationale

Packaged apps have the opportunity to have code run when a package is installed or updated via the
windows.preinstallConfigTask or windows.updateTask but have no equivalent option when a package
is uninstalled.

Applications can write data outside locations known by and managed by the Deployment stack (e.g.
locations under HKLM). Processes running in an AppContainer have constrained access to the system
so data is readily handled by Windows when a package is deregistered but MediumIL and elevated
processes can (and often do) write outside these managed locations. As a package can be removed
without the package's direct involvement a mechanism is needed to enable these apps to remove
data written to places or ways unknown to the Deployment stack.

'Reset' needs similar support. A 'reset' operation is functionally equivalent to
packageManager.RemovePackageAsync(p, RemovalOptions.PreserveApplicationData) but the package
package directory is not deleted followed by packageManager.AddPackageAsync(p). As this is
similar to but not exactly 'uninstall + install' the work performed by an uninstall task
may be inappropriate. Although an uninstall task could have a parameter indicating
Reason=<Remove|Reset> a separate specific task is simpler and more developer friendly.
In addition, the currently install/update task model is a separate task and
appxmanifest.xml schema.

A 'repair' operation is functionally equivalent to packageManager.RegisterPackageAsync(p) for a
package already registered to a user. However, register operations also occur for a loose file
package so there's no clear task to invoke for 'repair' scenarios. A windows.repairTask solves
this ambiguity.

Uninstall tasks must occur after a deregisteration operation is requested but before any
deregistration work can be performed. Thus, uninstall tasks are blocking operations. Similarly,
repair tasks are blocking operations. These should be time bound to prevent unconstrained delays
e.g. an uninstall task running for an hour would be a poor user experience.

Reset tasks are non-blocking to the Deployment pipeline. This occurs after Deployment work is
completed like a windows.updateTask. The latter have no time constraints imposed by Deployment
so reset tasks shouldn't need any Deployment imposed time constraints.

Scope

Important Notes

Links to related discussions:

• #16
• #2322

Open Questions

N/A