MSIX Supports multiple methods of handing scenarios where you want multiple packages that work together in some way.  Here is a list of the ones we know about.

 

Note: This article is a "work in progress" to capture everything we currently know on the topic.

Some of the options mentioned have not been fully vetted, nor necessarily tried by us.
  • Framework Packages:

Framework packages are generally packages that contain some common utility dlls needed by multiple packages.  Although it is possible to create your own framework packages, these are usually provided by Microsoft.  Often, all you need to do is reference the package as a PackageDependency in the AppXManifest file.  When your package is installed will automatically find and check if the dependent package is installed already.  Depending on the setting of the Optional parameter, and also depending on your package management/distribution system the framework package might get automatically installed if not present, or the installation of your package might be blocked until the framework package is provided, or the dependency could get ignored (likely causing an issue when the user runs your package).  In an AppAttach scenario, you must manage the installation of these framework packages independently.  The Microsoft provided framework packages usually are kept online in the Microsoft store, but also available from the Microsoft download sites.

When added to the AppXManifest, there is an optional parameter called "Optional", which will have a value of "True" or "False".  When not present on the line, the default value is "False".  In both cases, installation of this package will trigger a check to see if the package is already present, and if not to automatically acquire and install it.  This means access to the Windows Store, or potentially an in-house replacement source.  If Optional is not set to true, failing to get the dependency package installed will fail the install of the package.

For many of these framework packages, Microsoft regularly updates them for security fixes.  For these security fixes you do not need to update your package.

Example of framework packages provided by Microsoft include:

VC Runtimes:

VC Runtimes are support libraries for code written in unmanaged code (aka "win32 code"), including the vcruntime and mfc dlls. You have a choice of installing the non-packaged dependency directly in the package with the application, or referencing it as a package dependency this way.  Keeping the runtimes out of your package and managing a library package is considered to be better for security as the supported ones are frequently updated by Microsoft, which allows you to take that update without having to repackage the apps.  Some of the framework packages are in the current application lifecycle to receive security updates, and some are not.  See Latest supported Visual C++ Redistributable downloads | Microsoft Learn

If you specify the name as shown you will get the version that matches your package architecture (generally x64).  There is documentation that suggests we can add .x86 or .x64 to the name to get a specific version, however this does not work.  So these, especially if you need both in the same package, are not normally a good choice for repackaging traditional apps into MSIX.

For the supported versions, there is one ending with the version and another ending with the version dot UDPDesktop.  Each consists of a subset of the full restributable files.  The former has the basic vcruntime files while the latter has the mfc files.    

 Microsoft.VCLibs.140.00 and Microsoft.VCLibs.140.00.UDPDesktop  (for .Net Framework and Win32 apps packaged as MSIX that need Visual Studio Runtimes 2015-2022 (aka the "140" series)  Available separately as x86 and x64 packages. 

Microsoft.VCLibs.120.00 and Microsoft.VCLibs.120.00.UDPDesktop  (aka VC Runtime 2013 or  the "12.x" series)

Microsoft.VCLibs.110.00 and Microsoft.VCLibs.110.00.UDPDesktop (aka VC Runtime 2012 or the "11.x" series, no longer under support)

Microsoft.VCLibs.100.00 and Microsoft.VCLibs.100.00.UDPDesktop (aka VC Runtime 2010 or the "10.x" series, no longer under support) 

There are no known framework packages for the older VC runtime series.  In theory you could build your own if you still have a copy of that version installer, but as nobody is updating them it is probably easier to keep them into the package.

DotNet Desktop Runtimes:

These are for either packages containing programs written in the modern .Net frameworks (5 and above) and running in an MSIX/AppX package.  It is the support libraries for these apps to call into the windows api for OS support such as file and registry access.  The vendor application may or may not make an installation of the runtime as part of their application installer, or may just list it as a system dependency.  You can think of these like having a .Net Framework installation on your system as a dependency.  Similar to how within the .Net Framework 4.0 through 4.81 family you can just ensure you have the latest version and it supports anything in the 4 family (or .Net Framework 2.0 through 3.5SP1), with these it seems that you can just install the latest version in the 5 through 9 range (possibly the .Net 1, 2, 2,1, and 3 are in this range also).  At some time there might be a new family grouping for these .Net runtimes.  The support lifecycles on these are short, with odd numbers being "Long Term Support" of 5 years with the even numbers out of support after 3.

Microsoft.DotNet.DesktopRuntime.9

Microsoft.DotNet.DesktopRuntime.8

Microsoft.DotNet.DesktopRuntime.7

Microsoft.DotNet.DesktopRuntime.6

Microsoft.DotNet.DesktopRuntime.5

Here is an example of a downloading runtime from Microsoft: https://www.microsoft.com/en-us/download//details.aspx?id=102159&msockid=331fde52041d6a7d2ec5ca78053d6b9c

WindowsApp Runtimes

These are for either packages containing programs written in the modern .Net frameworks (5 and above) and using "WinUI" for the user interface, or for packages containing manifest elements that are implemented on the system by modern code. Currently, the desktop7 shortcuts are a manifest element known to require version 1.4

The Windows App Runtime is sometimes also referred to as "WinRt", or developers may know it as the "Windows App SDK" which is what they use in their code that ends up requiring one of these packages.

We suspect, but have not verified, that you need the version specified or higher.  These packages are architecture specific.

Microsoft.WindowsAppRuntime.1.2

Microsoft.WindowsAppRuntime.1.3

Microsoft.WindowsAppRuntime.1.4

Microsoft.WindowsAppRuntime.1.5

Microsoft.WindowsAppRuntime.1.6

 

 
  • Modification Package:   
The modification package allows you to create a package with customizations to a given package.  The use cases are to put optional plugin dlls, and/or application configuration settings.  The latter you can think of in line with how you have used MDT files for MSI installations.  The term "Modification Package" is used because this is the wording used in the Microsoft MSIX Packaging Tool if you want to create the modification package.  Ultimately, the modification package will have a reference to the primary package as a package dependency in the modification package AppXManifest file.
 
The modification package is layered "higher", meaning that if there is a conflict with the primary package for file or registry, the modification package will win.
 
The package reference in the primary package in its AppXManifest will use the full package name without version information, making it possible to update the primary app without touching the modification package in most cases.  The primary package contains no reference to the modification package.  The primary package must already be installed to add the modification package. 
 
In the case of plugins, multiple modification packages may be used, however layering order is dependent on the order of installation (so don't add filename conflicts).  If the plugin is just dlls, these may be placed in the root folder of the modification package or VFS/SystemX## folder or the VFS folder parallel to where they would be placed natively, depending on how the application finds its plugins.  If the app uses the registry to find them then match that location, root folder, or VFS/SystemX## folder.  It the app enumerates a directory, then use the appropriate VFS folder.
 
The modification package cannot include AppXManifest extensions that for example are used to add shortcuts, file type associations and shell extensions.
 
  • WebView2

Applications that want to host browser content can use the WevView2 interface that is supplied by Microsoft Edge.  The package that your package references as a dependency is not actually written as a packaged application, but native exe installed software that then leverages the packaged "Edge", allowing the calling code to be packaged or unpackaged.

The AppXManifest uses a special extension for such situations called "win32dependencies", and currently this package is the only known supported win32dependency package.  Microsoft documentation on this here: win32dependencies:ExternalDependency (Windows 10, Windows 11) - Windows UWP applications | Microsoft Learn  Also the developer documentation on WebView2 and the multiple ways they can use it is an interesting read for non-developers here: win32dependencies:ExternalDependency (Windows 10, Windows 11) - Windows UWP applications | Microsoft Learn

If you need this dependency in your package, you likely also need to add the internet.client capability to the AppXManifest file of your package.

  • Shared Package Container:
The Shared Package Container (SPC for short) allows you to build two completely independent packages that contain to AppXManifest references to each other, and run them in a single container at runtime.  For App-V fans, this is your "Connection Group" equivalent. 
 
The feature is supported only on Windows 11 and above.  Currently, it also requires admin access but Microsoft has said they are working to remove that restriction.
 
These may be full packages using the entire AppXManifest schemas, including shortcuts and the like.
 
A separate PowerShell command and XML file is used to add the group definition to the system.  The packages in the XML file are ordered for layering purposes, and all are considered to be "optional".  The SPC may be installed either before or after the packages.  Most deployment systems don't know about this feature today, so you are probably on your own to implement the SPC deployment.
 
  • Hosted Apps
Hosted apps allow you to build things that App-V fans will recall as scenarios for "middleware".  The example used in Microsoft Documentation is for a standard Python package that is used by multiple independent python script packages.  This might allow you to upgrade the python distribution without touching all those python script packages.  We think this probably works for Java also. 
 
The Hosted app may include exe and dll files, and there doesn't seem to be any restriction on AppXManifest elements in it, although if you added a shortcut to that package the shortcut would only use the Hosted app package separately.  The Hosted App package does need to declare itself and any exe's to be called externally to be specified in the AppXManifest using an extension schema.
 
This technique borrows from the Modification Package technique in the other packages that need the hosted app of using the middlewares Package Family Name without version as a dependency in the AppXManifest file.  Layering would be the external package (python scripts started with a shortcut) layered over the Hosted App Package.  Since you start the app using the external package, each scripting package runs in an independent container.
 
No known Management/Deployment software knows about Hosted Apps so it is on you to supply the dependent Hosted App Package.  The Hosted App package must be installed first.
 
Microsoft overview blog on this feature: Hosted App Model - Windows Developer Blog 
 
  • Related Sets
How many different ways can we skin this cat? And why are we skinning them?  Related Sets seem to be the result of another uncoordinated attempt to do similar things.
 
  • Optional Packages:
 We think this apples to Related Sets only, but maybe useful separately?
 
  • Dynamic Dependencies that are Packages
This is a developer thing, but you need to know it exists. It is a packaged parallel to how an unpackaged application uses a folder of dlls dynamically. 
 
Most of the time traditional apps use an installation method for dll finding and either place dlls in known locations, such as the System32 folder, the current working directory, Adding an App Paths registration, or modifying the Path variable, any of which can be used to that the app finds the dll at rutime.
 
Some traditional apps (.Net Framework apps) will instead make a call at runtime initialization to add their special folders into the list of places that will be used for dll searching, which affects only that running process (and potentially child processes).
 
In the packaged world, we have a bunch of ways to layer in stuff.  But here, the developer code can AT RUNTIME reference dlls that are in another package by using the package identity.  If the developer does this, you won't know it from looking at the packages, but clearly they'd need to document the dependency to you.