Inside MSIX
Demystifying MSIX Architecture, Development, Deployment and Troubleshooting
Latest posts
External Location
We talked recently about PackageVolume as one of the ways to stage packages. Let's turn our gaze to External Location, which plays a distinct role in MSIX, with similarities to - and important differences from - other options. Why is External Location? MSIX deployment provides a full-service software installation stack. The process is simple: collect your content, describe your package in an , and run makeappx.exe and signtool.exe to create a signed .msix to distribution and install. But...what if you already have a product with an existing installer? What if you need to extend your product with features uniq...
Activatable Extension Points
We often talk about "running an application", "launching an app", or "starting an app". This conjures up visions of spinning up a new process, giving the application life. For packaged applications, Windows has a specific term for bringing an application to life: activation. Bringing a packaged process to life involves more than ordinary unpackaged process creation. Windows calls this machine "activation". Activation does more than simply create a process. Among other things, it creates the new process with the appropriate package identity. Activation also verifies the package is in an appropriate state befor...
Is it MSIX? Part 3: Find Package and Application Identity with TASKLIST and PowerShell
We previously determined how to programmatically retrieve a packaged process' package and application identity. Now let's find MSIX package identity using existing tools. TASKLIST.EXE Using the packaged app from our previous example, we know the "image name" (aka executable filename) and that its PID (process ID) is 7664. lists packaged processes and their package names: That's overkill when we're interested in a specific process. We can use the (filter) option to limit the output to our target process: Or we can specify the image name and get the same result: The column is actually the package fu...
Is it MSIX? Part 2: Finding Package Identity with APIs
We previously determined how to tell if a process is packaged or unpackaged using Task Manager. Now let's find its package and application identity in code. Windows provides APIs to retrieve package and application identity for a process: If you prefer WinRT: Kernel mode What about kernel mode? Nearly all MSIX APIs require a user-mode caller. The Windows Driver Kit (WDK) provides RtlQueryPackageIdentity() and RtlQueryPackageIdentityEx() for querying package identity from a token. Tools? What about tools to do the same? Onward to Part 3... 1 returns but provides only the Package-Relative Application...
Is it MSIX? Part 1: How to Tell if a Process Is Packaged
Overheard in a recent conversation: Enterprise Administrator: "The ***redacted*** application is awesome, but it really should be an MSIX package." Microsoft Developer: "Ummm, it already is." That sparked another question: How can you tell if an application is packaged or unpackaged? Turns out there's a few simple ways to check. The key difference between packaged and unpackaged processes is whether they have package identity. Task Manager provides a convenient way to quickly see this: The list of processes now shows Package name: For example: In this example, ...
Footprint vs Payload files
Payload files Payload files are files stored in and delivered by the package. This includes your code, assets, and data, such as executables, DLLs, images, configuration files, and resources. For example: Content files The term content is sometimes used in MSIX-related APIs and documentation, but it does not provide as clean a classification as payload and footprint. For example, the Packaging API associates a content type with payload files. To avoid ambiguity, we'll use payload file when referring to files stored in the package. Footprint files Footprint files are package metadata and infrastructur...
PackageType: Main, Framework, Resource, Optional, Bundle
Every MSIX package is one of four package types: MSIX also supports Bundle packages. Bundles are somewhat different from those four package types: a Bundle is a container for one or more MSIX packages. Windows APIs nevertheless expose Bundle alongside the other package types when identifying packages. Each package type has its own behaviors, nuances, and rationale worthy of a dedicated discussion. We'll take a brief whirlwind tour of MSIX package types here and explore them in greater detail in future blog posts. What does imply? What does actually mean? MSIX packages have various properties and beh...
MSIX PackageVolume: How Package Storage Works
An MSIX package can be staged in several ways and locations: By far the most common is PackageVolume. We'll dig into the rest in future posts, but for now let's focus on MSIX PackageVolume. In the beginning... When MSIX first appeared in Windows 81 packages would be staged to a unique directory under . More specifically, packages were placed in a subdirectory named with the package's full name. For example: Every package has a unique package full name, and thus is staged to a unique subdirectory within its package volume. This is commonly referred to as a pkgdir. This illustrates one of MSIX's ...
Servicing While In Use and ERROR_PACKAGES_IN_USE
How does MSIX service a package while it's in use? Simple: It doesn't. A core principle of MSIX servicing is: Do not service a package while it's in use. Deployment provides several ways to deal with that constraint. Options range from terminating applications to deferring servicing until the package is no longer in use. How hard can it be? 'Servicing a package' means any deployment activity modifying software, including update, remove, repair and other operations. Altering installed software can be highly disruptive if the software is in use. Executables and DLLs may be mapped into running processes. File...