How to Create and Register a Sparse MSIX Package with External Location on Windows 10 and 11

The distinction affects anyone who ships Win32 software with its own installer and wants Windows features that need package identity. It also explains why some sparse-package builds fail in confusing ways.

What External Location actually does​

Microsoft Learn says package identity, also called a sparse package or packaging with external location, unlocks platform features that unpackaged apps can't use. These include toast and push notifications, background tasks, app extensions, share targets, file associations, startup tasks, privacy consent prompts and Windows AI Foundry APIs. None of this requires full MSIX packaging or a change to your existing installer.

Inside MSIX describes the mechanism. A package installed with an External Location gets an extra path at install time. That path tells Windows where the manifest-referenced payload files live. The package still has its normal install location, and the External Location supplements it rather than replacing it.

Windows still expects AppxManifest.xml, AppxBlockMap.xml and the other footprint files in the package's own install location. The files the manifest points to, such as the app's executable, are resolved from the external path. Whoever installed those files still owns them. MSIX doesn't repair, secure or uninstall them.

The 2019 Windows Developer Blog post that introduced the model says the same. An app using a sparse package with an external location isn't fully managed by the OS at deployment, runtime and uninstall. The app remains responsible for installing and uninstalling all its artifacts, including the sparse package and the external content.

Why the manifest flag matters​

The manifest must declare uap10:AllowExternalContent as true for the package to be installed with an External Location. According to Inside MSIX, a package with that flag must be installed with an External Location. Kapustein calls the name a misnomer and says "Require" would have been more accurate. Treat it as a requirement, not a permission.

Building a sparse package, step by step​

The Inside MSIX example is a fictional HelloWorld app. These are the steps, using the post's own example values.

1. Write the manifest. The example declares an Identity with a name, a publisher, version 1.2.3.4 and x64 architecture. It also sets AllowExternalContent to true and adds a TargetDeviceFamily with MinVersion 10.0.19041.0. The runFullTrust capability is declared. The app uses mediumIL trust and the packagedClassicApp runtime behavior. These are choices for that example, not rules for every app.
2. Stage only the files you want in the package. The sample script copies AppxManifest.xml and logo.png into a temporary working folder.
3. Pack with validation off. Run makeappx.exe pack /o /h SHA256 /d <workdir> /p <output.msix> /nv.
4. Sign the package. Run signtool.exe sign /fd SHA256 /f <pfx> /p <password> <output.msix>. The sample's password is obviously a placeholder. Don't paste a real one into a script you publish.
5. Check the contents. Open the MSIX as a ZIP, for example with .NET's ZipFile. The example package holds exactly five entries: logo.png, AppxManifest.xml, AppxBlockMap.xml, [Content_Types].xml and AppxSignature.p7x. There is no helloworld.exe.

What /nv does and doesn't do​

MakeAppx normally checks that package-relative files in the manifest are present in the content directory. The HelloWorld manifest names helloworld.exe, which isn't there, so a plain pack would fail. The /nv switch turns off that check.

Microsoft's guidance agrees. The Learn page says the /nv flag is required to bypass validation of referenced file paths in the manifest.

It has limits, though:

• /nv only lets the build succeed. It doesn't register an External Location.
• It doesn't check that the executable exists anywhere.
• It doesn't guarantee the package will install. Registration with an External Location is a separate step.

The logo exception​

"No payload" isn't quite true. A footnote in the post says a sparse package must contain the file named by the manifest's <Package><Properties><Logo> element. That is why logo.png is in the example archive.

Newer Microsoft tooling guidance for the winapp CLI treats visual assets differently. It says the visual assets the manifest references, such as StoreLogo and tiles, are resolved from the external content location at runtime, not from inside the .msix. The two aren't strictly contradictory. They describe different elements: the package-level Logo versus the application's visual elements. If you are unsure, check what your manifest references and test an install.

Registering the package​

The registration steps below come from Microsoft Learn.

1. Trust the certificate. The signing certificate must be trusted on the target machine. For development with a self-signed certificate, import the public .cer, not the .pfx, into the Trusted People store. If you skip this, registration fails with CERT_E_UNTRUSTEDROOT (0x800B0109). Use Cert:\CurrentUser\TrustedPeople, or Cert:\LocalMachine\TrustedPeople with elevation for machine-wide installs. Production deployments need a certificate that the target already trusts.
2. Match the publisher. The manifest's Publisher must match the subject of the signing certificate.
3. Register per user. Run Add-AppxPackage -Path <package> -ExternalLocation <app install directory>. Use the app's directory without an executable name.
4. Register per machine. Learn documents Add-AppxPackage -Stage with -ExternalLocation, followed by Add-AppxProvisionedPackage -Online.
5. Connect the executable. Add an application manifest with an msix element to the exe. Its packageName, publisher and applicationId must match the identity package's Name, Publisher and application Id.

Troubleshooting​

Microsoft Learn lists several common failures:

Microsoft also suggests the Event Viewer log under Applications and Services Logs, Microsoft, Windows, AppxDeployment-Server. It records deployment errors in more detail than PowerShell or the API result do.

One more note from Learn: AllowExternalContent arrived with Windows build 10.0.19041.0. If your app runs on older Windows, check the OS version in your installer and don't register the package there.

When to be less sparse​

Kapustein's practical point is that you may include payload in the MSIX, but Windows won't use it to satisfy manifest references. Windows still stages those files in the package's install directory, with the usual integrity options. Your own code can read them there. This is worthwhile for files the manifest doesn't reference.

His example is a DSCv3 resource definition named helloworld.dsc.resource.json. The steps are:

1. Put the file in the MSIX.
2. Install the rest of the app with your existing installer.
3. Register the package with an External Location.
4. Find the file through the package's InstalledPath.

The sample uses PackageManager.FindPackagesForUserWithPackageType with the package family name. It returns the combined path only when exactly one package matches, and returns null otherwise. A planted file in the External Location is ignored, because the code never looks there.

To make this tamper-evident, enable package integrity enforcement. Microsoft documents the manifest element uap10:PackageIntegrity with uap10:Content Enforcement="on". The documented behavior is:

• Windows runs integrity checks and starts remediation before launching an app it finds tampered or corrupt.
• default behaves the same as off.
• For apps from outside the Store, users get a generic dialog directing them to Settings to repair or reset the app.

What this does not protect​

• A sparse package doesn't automatically have enforcement on.
• Files in the External Location aren't covered by these checks. They stay under the other installer's control.
• The "usually a few KB" figure is the post's rule of thumb. Real size depends on what you include.

Why it matters​

Some developers avoid MSIX because they can't give up their installer. Others add a "sparse package" step without understanding what it does. Seeing External Location as the feature, and sparseness as an optional trim, helps you make three choices well:

• What goes in the package. Put in files you want staged and protected.
• What stays external. Leave the executable and anything the manifest references to be resolved from the external path.
• Who owns repair and uninstall. Your installer does, for everything outside the package.

If your sparse package builds but the app has no identity at runtime, check these in order: the msix element match, the External Location path, and certificate trust.