Nested Packages Deployment
In the scope of package deployment, it is possible to install and uninstall MSIX packages that are part of the installation. This functionality can be used, in particular, to deploy MSIX Sparse Packages that provide access to new Windows APIs and UWP features such as BackgroundTasks, Notifications, LiveTiles, Share, and others.
During monitoring, the program automatically detects MSIX packages deployed by the repackaged installation and creates corresponding entries in the Nested Packages view Pic 1, which is displayed when the Nested Packages node is selected in the Projects view. You can review automatically created nested packages, as well as modify, delete or add new packages manually using this view. You can also change the nested packages deployment order and exclude/include a package from the build. To modify nested package properties, you can use the Edit action available in the context menu.
There are two types of nested MSIX packages that can be managed in the Nested Packages view: nested MSIX packages and replicated MSIX packages. Below is detailed information about each type. You can use the following actions to create different types of nested packages.
|
Nested MSIX Package The Nested MSIX Package button from the New group on the regular Project and contextual Nested Packages Ribbon pages should be used to add a new nested MSIX package to the currently configured project. |
|
Replicated MSIX Package The Replicated MSIX Package button from the New group on the regular Project and contextual Nested Packages Ribbon pages should be used to add a new replicated MSIX package to the currently configured project. |
Nested MSIX Packages
Nested packages enable the deployment of existing MSIX packages within the scope of the parent package. If you use monitoring to capture changes of an installation that deploys some MSIX packages, these packages are detected and added to the generated project as nested MSIX packages. This ensures that the repackaged installation will also deploy them. During the repackaging process, nested packages are created and configured automatically, or you can create them manually in the Nested Packages view. Nested MSIX packages have several configurable properties Pic 2.
When you configure a new package, you need to choose an Operation for the package, such as Install or Uninstall. If you configure a package installation, you must choose a package file to be deployed from those stored in the project; select it in the Package File field. If you are deploying a Sparse Package, you also need to specify a folder in the External Location field that is set as the root for the installing MSIX package. Additionally, you must configure how a package should be deployed in the Apply To field, whether it should be deployed to the current user, all users or use the same settings specified for the owner MSI package.
To configure package uninstallation, you must specify package uninstallation conditions such as Package Name, Publisher, Architecture, and Version Pic 3.
The program will uninstall only those packages that meet the entered conditions. To automatically fill in these fields, you can use the Read Identity from Package button, so conditions are extracted from the selected package file, and the program will uninstall only packages with the same identity during deployment. You can configure to uninstall multiple packages at once by specifying regular expressions in the package properties. The program also supports simple placeholders, so you can use "*" as a replacement for varying string width and "?" as a replacement for one symbol. You can leave the Publisher and Version values empty, so they aren’t evaluated to find suitable packages.
Replicated MSIX Packages
In some cases, a nested MSIX package file may not be available during installation packaging. For example, when monitoring a package installation from the Windows Store, the installation happens, but the MSIX package file used for this process may not be available afterward. In such situations, replicated MSIX packages can be used to package these installations.
During monitoring, the program automatically detects the deployment of MSIX packages. If the MSIX package file itself is unavailable, the program uses the deployed MSIX manifest file to replicate the deployment of the nested MSIX package. A corresponding entry for the replicated package is automatically created and displayed in the Nested Packages view. Additionally, you can manually create a replicated MSIX package entry in the project.
To manually create a replicated MSIX package, the program prompts you to specify the path to an MSIX manifest file, analyzes its content, and creates a corresponding entry in the installation project. During the parent package generation, the replicated package configuration is used to create a nested MSIX package, which is deployed as part of the parent package installation.
MSIX packages must be digitally signed, and the program signs them using the digital signature configured in the installation project or in the Package Signing Page of the program Preferences depending on the configured digital signing options. To generate a package with a replicated MSIX package, a digital signature must be enabled and specified.
You can modify the content of a replicated MSIX package by editing it. On the General tab, you can view the main properties of the replicated package. You can change the package name, version, architecture, and other properties Pic 4.
On the Package Files tab, you can review a list of file system resources deployed by the replicated package. When you create a replicated package, this resource list is generated based on the package's manifest file Pic 5.
If needed, you can add new files to the replicated package or remove existing ones. The files listed in this view will be included in the MSIX package, which will be automatically generated and added to the parent package.