MSIX

Calculating hash part of MSIX Package Family Name

Package family name is important property, that describes each MSIX package installed on Windows 10 / Windows 11. It consists of package name, concatenated with a special string of 13 letters and numbers. There are many places where this value is used, but the most easy one to spot is that it builds the folder path, under which all MSIX files are saved.

For example, the package family name of MSIX Hero is MSIXHero_2.2.56.0_neutral__zxq1da1qqbeze. You can see the family name by invoking a PowerShell command let Get-AppxPackage <name> and scrolling to PackageFullName

… or by opening the package in MSIX Hero, which also shows the value:

The first part of the family name is just simply a package name. This is something the author defines in the manifest file. More interesting is the second part – it seems to be not written directly into the manifest, for the very package is always the same on all machines and seems to change when the publisher changes. For this reasons, it is sometimes being called a “publisher hash”. It also has an interesting properties:

  • It is always a string of exactly 13 letters and/or numbers
  • It avoids certain letters (for example “i” and “o” – you will never find them in the family name).
  • Changes together with the full publisher name. Changing the display values and other package identification does not have impact on it.

This post will explain how the value can be calculated and how to implement the algorithm in C#. Since the hash algorithm is constant on all machines, you do not have to install the package to know its family name / publisher hash.

Continue reading →
Posted by Marcin Otorowski in MSIX, 0 comments

Executing custom commands in MSIX context

Sometimes, for troubleshooting it may be necessary to invoke commands in the context of MSIX, so that all virtualized file and registry resources are available. There are three main use cases for it:

  1. Testing out whether the files and registry entries are visible inside the virtual package in the correct place as defined in the AppxManifest.xml.
  2. Testing out whether Modification Package correctly merges its VFS and virtual registry with the base package.
  3. Executing your app from the MSIX package with custom executables and/or parameters which are not necessarily exposed as entry points.

There exists a really useful PowerShell cmdlet which does the heavy lifting, the only thing the user has to do is to supply the right parameters. Its signature (from MSDN):

Invoke-CommandInDesktopPackage
      [-PackageFamilyName] <String>
      [-AppId] <String>
      [-Command] <String>
      [[-Args] <String>]
      [-PreventBreakaway]

Both PackageFamilyName and AppId are required, as well as the command to be executed. You can get the two values from another cmdlet Get-AppxPackage.

The command that is started in the “bubble” can be pretty much anything (it is validated before running), but some typical examples are:

  • cmd.exe
  • powershell.exe
  • regedit.exe
  • Executables being part of the package (indirectly)

For example, let’s execute a PowerShell session in MSIX container to verify the virtualized file structure.

Continue reading →
Posted by Marcin Otorowski in MSIX, PowerShell, 0 comments

Creating MSIX Packages with RayPack 6.1

Last week I was in London, and had a chance to speak to a few MS guys standing behind #MSIX. Also last week, a new version of RayPack Studio has been released, bringing some improvements over MSIX conversion in the latest revision 6.1. With this post I wanted to make a quick walkthrough of going from so-called legacy installations (traditionally all setup.exe and alike, but recently the Windows Installer format has been counted to that group) to the new, modern and native Windows-10 way of installing and servicing apps.

Installing Firefox in MSIX format (auto-conversion from MSI)
Continue reading →
Posted by Marcin Otorowski in MSIX, 0 comments