Inside MSIX
Demystifying MSIX Architecture, Development, Deployment and Troubleshooting
Latest posts
Package Identity
An MSIX package identity is composed of a five-part tuple that uniquely identifies a package. It consists of the following attributes: Together, these fields form the canonical identity of a package. Programmatically, this identity can be represented using APIs such as Windows.ApplicationModel.PackageId or the PACKAGE_ID structure. Why Package Full Name? Working directly with the individual identity fields is often inconvenient. To simplify common scenarios, Windows defines an opaque string representation that encapsulates the entire five-part identity: the Package Full Name. This canonical form provi...
Is This a Packaged Process?
Sometimes you need to know whether the current process has package identity. Certain Windows features require it, and behaviors can differ—both technically and culturally. For example, classic Windows applications often store settings in the registry, whereas packaged applications typically use ApplicationData.LocalSettings. So how can your code determine whether it is running with package identity — that is, whether it is a packaged process? Terminology Let's begin with clear and unambiguous definitions: We deliberately say process rather than application. The distinction matters: applications have pro...
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 system queues the request in the deployment engine’s memory for process...