{"id":380,"date":"2026-10-27T09:00:41","date_gmt":"2026-10-27T16:00:41","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/insidemsix\/?p=380"},"modified":"2026-10-25T23:53:51","modified_gmt":"2026-10-26T06:53:51","slug":"msix-external-location","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/insidemsix\/msix-external-location\/","title":{"rendered":"External Location"},"content":{"rendered":"

We talked recently about PackageVolume<\/a> as one of the ways to stage packages.<\/p>\n

Let’s turn our gaze to External Location, which plays a distinct role in MSIX, with similarities to – and important differences from – other options.<\/p>\n

Why is External Location?<\/h2>\n

MSIX deployment provides a full-service software installation stack. The process is simple: collect your content, describe your package in an AppxManifest.xml<\/code>, and run makeappx.exe and signtool.exe to create a signed .msix to distribution and install.<\/p>\n

But…what if you already have a product with an existing installer? What if you need to extend your product with features uniquely requiring MSIX? For example, if your application needs to run with package identity to access resources requiring identity? Or you need to add Share Target<\/a> support? Or File Explorer context menus in Windows 11<\/a>?<\/p>\n

Before External Location, this meant replacing your existing installer with an MSIX package. This can be costly for some, or simply not possible if MSIX doesn’t support all your deployment needs.<\/p>\n

If only an existing installer could incrementally leverage MSIX…<\/p>\n

And thus was born External Location<\/strong>.<\/p>\n

What is External Location?<\/h2>\n

A package with an External Location is installed with an additional path, specified at install time. This tells Windows where to find the package\u2019s payload files<\/a>, separately from its install location.<\/p>\n

Example without External Location<\/h3>\n

For example, create Contoso.PointOfSale-v1.2.3.4-x64.msix<\/code> using this AppxManifest.xml<\/code> fragment:<\/p>\n

<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<Package ...>\n  <Identity Name=\"Contoso.PointOfSale\"\n            Publisher=\"CN=Contoso LLC, O=Contoso LLC, L=Paris, C=France\"\n            Version=\"1.2.3.4\"\n            ProcessorArchitecture=\"x64\" \/>\n  ...\n  <Applications>\n    <Application ... Executable=\"PointOfSale.exe\">\n...\n<\/Package>    \n<\/code><\/pre>\n
Now install<\/a> the package, e.g.<\/p>\n
Add-AppxPackage C:\\Packages\\Downloads\\Contoso.PointOfSale-v1.2.3.4-x64.msix\n<\/code><\/pre>\n
As a result, Windows stages the package at C:\\Program Files\\WindowsApps\\Contoso.PointOfSale_1.2.3.4_x64__eh4htm4n7tdre<\/code>, containing AppxManifest.xml<\/code>, PointOfSale.exe<\/code> and the rest of the package’s contents.<\/p>\n
Windows launches C:\\Program Files\\WindowsApps\\Contoso.PointOfSale_1.2.3.4_x64__eh4htm4n7tdre\\PointOfSale.exe<\/code> when you activate the app.<\/p>\n
Example with External Location<\/h3>\n
Installing a package with an External Location requires adding <\/a> to AppxManifest.xml<\/code>:<\/p>\n
<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<Package ...>\n  <Identity Name=\"Contoso.Invoice\"\n            Publisher=\"CN=Contoso LLC, O=Contoso LLC, L=Paris, C=France\"\n            Version=\"4.1.2023.0\"\n            ProcessorArchitecture=\"x64\" \/>\n  <Properties>\n    ...\n    <uap10:AllowExternalContent>true<\/uap10:AllowExternalContent>\n  <\/Properties>\n  ...\n  <Applications>\n    <Application ... Executable=\"Invoice.exe\">\n...\n<\/Package>    \n<\/code><\/pre>\n
and an additional path, specified at install time.<\/p>\n
Assume your existing installer has placed Invoice.exe<\/code> and its supporting files in D:\\MyApps\\Contoso<\/code>.<\/p>\n
Add-AppxPackage C:\\Packages\\Downloads\\Contoso.Invoice-v4.1.2023.0-x64.msix -ExternalLocation D:\\MyApps\\Contoso\n<\/code><\/pre>\n
As a result, Windows stages the package at C:\\Program Files\\WindowsApps\\Contoso.Invoice_4.1.2023.0_x64__eh4htm4n7tdre<\/code>, containing the package’s contents.<\/p>\n
But…at runtime, activation uses D:\\MyApps\\Contoso\\Invoice.exe<\/code>.<\/p>\n
Location, Location, Location<\/h2>\n
A package always has an Install<\/strong> location. This is C:\\Program Files\\WindowsApps\\Contoso.Invoice_4.1.2023.0_x64__eh4htm4n7tdre<\/code> in the Invoice example above.<\/p>\n
A package may also have a per-machine External Location<\/strong>. This is commonly referred to as the Machine External Location<\/strong>.<\/p>\n
Also.<\/p>\n
The External Location doesn’t replace the install location. Instead, it supplements it.<\/p>\n
P.S. A package may also have a per-user External Location, but this is rarer and has its own story and nuances. We’ll discuss this in a future post. For now, assume “External Location” mentioned in this post always means a Machine External Location.<\/p>\n
What External Location does<\/h2>\n
A package’s External Location tells Windows where to find the package’s payload<\/strong> files.<\/p>\n
Windows still expects AppxManifest.xml<\/code>, AppxBlockMap.xml<\/code> and other Footprint files<\/a> in the package’s install location, e.g. C:\\Program Files\\WindowsApps\\Contoso.Invoice_4.1.2023.0_x64__eh4htm4n7tdre\\AppxManifest.xml<\/code>.<\/p>\n
Windows normally looks for files referenced in AppxManifest.xml<\/code> at the package’s install location. The magic of External Location is to tell Windows somewhere else<\/em> to look for those files:<\/p>\n