Inside MSIX
Demystifying MSIX Architecture, Development, Deployment and Troubleshooting
Latest posts
Display Name is for Humans
Package identity exists for one primary purpose: This is a considerable improvement over the historical tendency to assign UUIDs and GUIDs to nearly everything - including things that humans were expected to discuss in meetings. Identity Is for Systems A package's Name, Package Full Name, and other identity-derived values are intended for developer and system use. These identifiers prioritize correctness, uniqueness, and programmatic consumption - not clarity or friendliness from an end-user's perspective. Identity must remain stable across servicing operations and dependency resolution. If it changes, the...
Package Status
Every package has a set of status flags describing its current health and availability. These can be queried via the Package.Status property. A package may report more than one status value at a time if multiple conditions apply. Package Status Groups The various states fall into three groups: NeedsRemediation Status values in the NeedsRemediation group indicate that the package is in a bad or broken state and must be repaired before it can be used. NotAvailable Status values in the NotAvailable group indicate that Windows has the package installed, but it cannot be used at this time. ...
Applications Are Not Packages
Applications are not packages. Let me repeat. Applications are not packages. This is a common misconception due to the (too) often blurring of concepts and terminology. Packages and applications are different and distinct things, so it's important to understand what those words mean (to MSIX). Packages and Applications Are Different Things An application is distributed via a package. That's not the same as being the package. A package is a unit of distribution and deployment. You can install a package, or update a package, or remove a package. You can't install half a package, or remove part of a package. A...
MSIX Per-User vs All Users: Install, Provision, and Uninstall Packages
MSIX supports making a package available to all users; the formal term is provisioning. Provisioning a package family makes it available to all users, whereas registration makes a package available to a single user. Per-User vs All Users Traditional installers often provide a "per-machine" installation mode to make software available to all users. In MSIX, the equivalent user experience is achieved through provisioning. To install a package for all users, first stage the package on the machine and then register it for each user. To facilitate this, Deployment manages a 'list of provisioned package families' an...
Add vs Stage and Register
As previously mentioned to 'install' a package, as people think of the term, Windows actually performs two separate operations: staging and registration. To oversimplify: One way to 'install' a package for a user is to explicitly stage it, then register the package: But this scenario is common enough that deployment handles it more efficiently as a single deployment operation: stage the package and register it in one request. That's what the 'Add Package' operation does: ensures the package is staged if necessary, then registers it for the user. Why not always Add? Because staging and registratio...
Third Rule of MSIX
MSIX has several core principles underlying its design and implementation. Engineers half-jokingly call these The Rules of MSIX. The Third Rule of MSIX is arguably the most important and certainly the most foundational: Package identity is unique across space and time Packageidentity is a unique identifier corresponding to a specific set of bits. Change even a single bit in the package and the package identity must change as well. The deployment engine relies on this rule when deciding if a package needs to be staged. If an existing package already has the same identity, deployment skips staging work. This...
Staging Part 2 – Disk Space Optimization
"Disk space optimizations" is one of the key features of MSIX: Disk space optimizations. With MSIX there is no duplication of files across apps and Windows manages the shared files across apps. The apps are still independent of each other so updates will not impact other apps that share the file. But how does MSIX accomplish this? Every package includes an , which lists all files in the package along with their corresponding hashes. In Windows 8 - when MSIX was first introduced1 - staging would extract every file from the package directly into a file within the package's install location (also known as t...
Staging Part 1 – Sharing is Caring
A key phase in installing a package is staging the package: When a package is staged for the first time, deployment performs several actions, including: Deployment secures these directories with strict permissions, typically granting users Read and potentially Execute access - but notably not Write access. This ensures one user cannot modify the contents of a package in a manner that would compromise their own environment - or anyone else's. Because MSIX guarantees the immutability of the pkgdir after staging, it can be safely shared across all users on the system - regardless of who installed the p...
Deployment Operations, Requests and Queue
The PackageManager API submits requests to the deployment engine for processing. Each request represents an instruction for the deployment system to carry out a defined set of actions, collectively referred to as a deployment operation. The operation associated with a request depends primarily on the API used to initiate it and, in some cases, its parameters. Internally, the deployment pipeline models its work as a series of deployment operations derived from an API called and its arguments. For example, PackageManager.MovePackageToVolumeAsync() submits a request to perform a Move Package operation. In most cas...