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

Publishing to winget with MSIX Hero

MSIX Hero is a freeware tool used by administrators and packagers for troubleshooting, analysis and debugging of MSIX packages. One of the latest updates introduced a new functionality – the ability to edit and create YAML manifests – a format accepted by winget package manager.

Winget is the newest approach from Microsoft, which aims to offer a centralized, format-agnostic package manager. While it differs substantially from what Linux/UNIX package managers and even Chocolatey, Scoop etc. offer, there seems to be rather a positive reception by the community. Once some missing features are there, together with constantly growing number of apps available, it may eventually become a really interesting part of the ecosystem, possibly one of the first thing the user would install to get his beloved apps and stuff on his newly staged computer.

In this blog post, I will show how to get started, create and validate an app definition and finally push it to the repository. Some basic knowledge of git would help you to get started (as the publishing process relies heavily on a proper git-based workflow), but this guide has been written for git beginners in mind. Just make sure you have a free GitHub account – register for a new one if you do not have any yet.

This tutorial is specifically addressed to those, who may not be quite proficient with git and related stuff, but want to still be able to publish submissions to winget. Users working with git on daily basis can certainly skip large parts of sections, describing how to fork and sync repositories.


The app that I am going to publish will be the newest version 1.0.5 of MSIX Hero. The app is going to be an update of a previous version which is already in winget, but every submission is more or less following the same steps, regardless of being a completely new app, or just an updated version.

The first step is to prepare the sources. The app must be installable silently (with or without command line switches) and redistributable as a single file. The format itself is less important, most popular choices are:

  • MSI (Windows Installer) (note: because the file must be completely standalone, make sure that all your files and CAB archives are compressed inside the MSI container)
  • EXE (any format would work, some typical would be setups created by InnoSetup or NSIS).
  • MSIX/APPX (preferred choice for the modern deployment).

MSIX Hero is an MSIX app. The steps for other types are mostly the same.

Continue reading →
Posted by Marcin Otorowski, 1 comment

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):

      [-PackageFamilyName] <String>
      [-AppId] <String>
      [-Command] <String>
      [[-Args] <String>]

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