TMEditX  The Ultimate MSIX Package Editor plus MsixDeploy To Documentation Index

MsixDeploy Introduction

 

Also included with TMEditX, MsixDeploy is a testing tool for use with your MSIX Packages.  Fans of my App-V tools will recognize the functionality as the MSIX equivalent to AppV_Manage. 

We are finding that many users consider this tool to be the starting point to work with packages as it covers most all of the aspects of finishing and testing your packages, including the ability to launch TMEditX from a MSIX file.

Currently you can use this tool to provide an integrated environment where you can:

  • Locate, Edit, Install, and uninstall MSIX  and MSIXBundle packages on your test machine.
  • Locate, Edit, Install, and uninstall CIM formatted packages on your test machine (may require 21H1 or 21H2 for some functinality)
  • See installed packages and compare against the share.
  • Create, Locate, Edit, and Install/uninstall using AppInstaller files.
  • See installed appinstallers and compare against the share.
  • Create, Locate, Edit, Install/uninstall SharedPackageContainer files.
  • Look into package installation performance.

 

The tool uses different tabs for each of the main elements you might interact with, all described below.

 

Settings

The Settings tab allows you to specify the storage location for MSIX packages.  Typically this is a network share.  There is also a setting that can limit the number of levels of subfolders for which to search for the packages.  When this level is set to 0 it will search the full tree, when set to 1 it will only find packages in the folder specified, or for example set to 2 to look up to one folder level down.  Often you might establish an "Archive" folder to store obsolete packages and you don't want the tool finding those. Be sure to click that Apply button!

Like TMEditX, the tool supports systems that have enabled "dark mode".  Here is the same screenshot with the tool in Dark mode:

 

Packages

The tool automatically searches both the UNC path specified in the Settings, and queries the system for all installed AppX/Msix packages.  These are displayed in two different coordinated lists and you can flip between them using the radio buttons. Details are extracted from each of the UNC files, or from the installed packages.

Shown below is an example of the UNC list (click on images for dark mode view). Right-click on an item for appropriate context menu support.  You can also see the following:

  • Both AppX and MSIX packages are supported.
  • If the package is installed. 
  • Whether or not it is signed and if your system has the certificate installed.
  • The type of package (MSIX, AppX, and if it is a Modification package)
  • If the package uses the Psf, and if so what fixups.
  • File sizes and compression ratio.

And here is the list of installed packages from the system (independent from the UNC share).  By default the tool will ignore packages signed by Microsoft, but you can change that in the checkbox. Right-clicking on an item produces a context appropriate menu as well.

 

AppInstallers

AppInstaller files are often used in web deployment of packages, however internal UNC use is permitted.  The AppInstaller file will point to a remote source of a package/bundle file (and possibly associated items), and installing the appinstaller file will both add the package and allow for the possibility of automatic updates.  If the updates were asked for in the file, the system will check with the source of this file for updates, allowing you to create a new updated package and deploy by just updating this file on the web-site/share.

Like the Packages tab, the AppInstallers tab shows files found in the share defined in Settings, as well as those that have been installed (whether or not on the share).  The radio button allows you to switch between these views and there is a synchronization field to show those both in the share and currently installed. This tool detects files with .appinstaller file types, as well as .xml file types that use the correct schema.  A right-click provides an install menu.

You may create a new AppInstaller file (or edit an existing one) in the tool. 

Note: The tool does not yet support the selection/detection of Bundle files.  If a reference to one is found in the appinstaller file, you will see the reference but be unable to add a new one.

Details about AppInstaller Update Settings:

  • If any of the "Force Update any version", "On Launch", or "Automatic Background" checkboxes are selected, the Update element is added into the appinstaller file.
  • Although part of the Update element of the schema, The "Force Update any version"  is effective in the file being deployed. It allows for downgrade of the MSIX version.  We recommend always selecting this when deploying as it allows for you to roll back a bad version.
  • Without either of On Launch", or "Automatic Background", the client OS will not check for updates to the AppInstaller File once installed.
  • Both "On Launch" and "Automatic Background" may be selected.
  • When "On Launch"  is selected, the client OS will check for appinstaller file updates when the user launches the app.  This is done in the background and doesn't interfere with app use, unless modified by additional options available.  The updated app would be available to the user on subsequent launches. 
    • To conserve performance, by default behavior for On Launch is that this check is not made if it was last checked within 4 hours.  The 4 hour period may be changed by entering the number of desired hours in the "Hours Between checks" field.
    • "Show prompt" is disabled by default.  Enable this checkbox if you want the update installations to prompt.  Launching the original appinstaller file using the FTA will result in the AppInstaller prompt when the package is installed (which may be avoided by using the PowerShell command instead).
    • Only available if "Show prompt" is checked, "Updates blocks launch" may be set to block the app launch if an update is detected.  Using this option implies that the OS will always delay the launch of the application in order to complete the check for updates before launching the app. 
  • When "Automatic Background" is selected, the client OS will check for appinstaller file updates every 8 hours, even when the app is unused.

In all cases, updates occur in the background without user intervention.

 

SharedPackageContainer

The Shared Package Container feature is a similar concept to the App-V Connection Group.  It allows multiple, independent, packages to be run inside the same container and potentially use file and registry resources from each other. It defines an ordered set of packages that layer together whenever an app from one of the packages is started.  Unlike the App-V Connection group, all listed packages are optional (there is no designation for mandatory) and there is no equivalent to a priority group (thus you should only add a package to one group, except possibly for framework packages).

The feature requires an appropriate OS release to be fully available.  The feature missed the 21H1 OS release but is anticipated to arrive with the 21H2 release (and is in insider builds as this is written).

This tool supports the creation of SPC files, detection of these files on the share, and installed SPCs on the system.  You can switch between UNC file and installed displays, and synchronization of files and installs are provided.  The package list in the Shared Package Container definition also highlights which packages are currently installed.

This is the UNC display, shown on a system that does not support the feature.  Without OS support the Install context menu is missing.

Here is a system with support, shown in "dark mode".  

 The tool has an editor to create new/edit existing SPC files.  The SPC file is an XML file and Microsoft has not yet designated a file extension.  The tool suggests .msixSPC, but .xml is supported also.

 

 

Performance

While building the tool we detected some event based data in the OS that provides insights to the package installation performance.  The data may not be actionable, but is "interesting".  Hover the mouse over a color to see the detail of what part of the installation it represents.  It is especially illuminating to see just how often the Microsoft provided packages are updating.