There is no Install – it’s ‘Stage’ and ‘Register’

“Is ContosoParts.msix installed?” is a common – but misleading – question

The term install is not a formal concept in MSIX.

This may seem paradoxical for a deployment technology, but it makes perfect sense once you understand MSIX deployment’s core architecture.

Deployment Requests

A caller makes a deployment request to the deployment engine via the PackageManager API to perform some activity. This may involve adding a package to the system, removing one, or performing another management operation. Deployment requests include:

• the requested action
• the target package
• API parameters supplied by the caller
• contextual information about the requesting user (e.g., user ID and security context)

The system queues the request in the deployment engine’s memory for processing by the deployment pipeline.

The Deployment Pipeline

The deployment pipeline processes requests through an ordered set of steps. The pipeline may short-circuit or skip some steps, depending on the request and system state. At its core the processing consists of three primary stages:

• Index
• Stage
• Register

Index

Parse the incoming package’s metadata (for example, AppxManifest.xml) and store that information along with system metadata such as the intended installation path.

Stage

Create the package’s target installation location (also known as the package directory, or pkgdir).

Acquire the package payload and extract it into the pkgdir, and apply appropriate ACLs to secure the content.

Register

Associate the staged package with a specific user profile.

This may involve, among other actions:

• creating Start Menu entries
• registering file type associations
• configuring runtime data

Registering the package effectively makes it usable for that user.

Per-Machine vs Per-User

Indexing and Staging are per-machine activities. The system performs these once per machine.

Staged packages are stored and shared across all users on the system, with the pkgdir secured to allow Read and Execute access — but not Write access — to users.

Registering is a per-user activity.

This separation enables MSIX to alter the set of available packages for one user without affecting others. This isolation — and the controlled servicing it enables — is a cornerstone of MSIX’s design and is reflected in many platform behaviors and APIs.

So… Installing?

To make a package available for a user for the first time, a caller might invoke an Add API:

var packageUri = new Uri("C:\\Packages\\ContosoParts.msix");
var options = new AddPackageOptions();
var packageManager = new PackageManager();
var result = await packageManager.AddPackageByUriAsync(packageUri, options);
...

This sends an Add request to the deployment engine, which:

• Indexes the package
• Stages the package into a new pkgdir
• Registers it for the user

At no point did we technically “install” anything.

Even though we just installed the package 🙂