MSIX Start Menu Shortcut Icons are Incorrect

You may attempt to package an MSIX and upon testing, realise that the MSIX Start Menu shortcut icons are incorrect.  That is, the shortcuts may contain duplicate icons or the shortcuts may be missing completely and have failed to capture!

The reason for this is typically because we have captured an application that installs multiple shortcuts pointing to the same executable, but with different arguments/parameters that perform different functions.  For example:

Shortcut 1 (runs main app): C:\Program Files\Alkane\App.exe

Shortcut 2 (runs app config): C:\Program Files\Alkane\App.exe -config

And even though they have different icons in the Start Menu at time of capture, the MSIX capture process interprets them as being “the same executable”, and either uses the same icon for each shortcut in the MSIX package or omits capturing the shortcut altogether!

MSIX Start Menu Shortcut Icons are Incorrect

There are a couple of ways to resolve the issue of MSIX icons being incorrect.  The first approach is slightly “hacky” should we say, but it works.  We will use the aforementioned executable path as an example for both:

Approach 1 – Fixing MSIX Shortcuts During Capture

Essentially what we do here is make a copy of the target executable during the capture process and trick the MSIX packager into thinking it’s a different executable, and hence it will generate the appropriate icons.  We then edit the package to point the shortcut back to the original executable, and delete the copy we made.

  1. Start capture.
  2. Install application.
  3. Make a copy of C:\Program Files\Alkane\App.exe and call it (for example) C:\Program Files\Alkane\AppConfig.exe
  4. Change the shortcut that points to C:\Program Files\Alkane\App.exe -config to point to C:\Program Files\Alkane\AppConfig.exe -config
  5. Stop the capture.
  6. In the Package Editor tab of the MSIX packager, under the Manifest File section click Open File. Replace all instances of AppConfig.exe in the AppxManifest with the original App.exe. Save and close the manifest file.
  7. Go to the Package Files tab, and delete AppConfig.exe.
  8. Save and close the package.

Approach 2 – Retrospectively Fixing MSIX Shortcuts Post Capture

If we were retrospectively fixing the icons without recapturing the application, we must do a few things:

  1. Create new icons!  There is a free application that can assist, given an initial PNG file.  Save the new icons into a staging directory called, for example, C:\Alkane\NewIcons.
  2. Extract the MSIX by renaming the extension from .MSIX to .ZIP and extracting.
  3. Copy the new icons from C:\Alkane\NewIcons to the Assets directory of the extracted package.
  4. Update the shortcut icon names in the AppxManifest.xml for the relevant application (typically within the <VisualElements> node).
  5. Regenerate the Resources.pri file (Windows SDK required).
  6. Recompile the MSIX (Windows SDK required).
  7. Sign the MSIX (Windows SDK required).

Luckily, our free MSIX packaging tool can do all this in a few lines of code:

Install-Module AlkanePSF
Import-Module AlkanePSF -MinimumVersion 2.2.3 -Force

#configure AlkanePSF
Set-AlkanePSFConfiguration -MSIXInputFilePath "C:\Alkane\Test.msix" `
-MSIXOutputFilePath "C:\Alkane\Test-fixed.msix" `
-MSIXStagingFolderPath "C:\Alkane\Staged\" `
-MSIXCertificateFilePath "C:\Alkane\alkanecert.pfx" `
-MSIXCertificatePassword (ConvertTo-SecureString "AlkanePassword" -AsPlainText -Force) `
-MSIXArchitecture "64" `
-PSFType "TM" `
-TimManganZipUrl "https://github.com/TimMangan/MSIX-PackageSupportFramework/blob/develop/ZipRelease.zip-v2024-10-26.zip?raw=true"

#install prereqs (SDK, Tim Managan's PSF etc)
Install-AlkanePSFPrerequisite -ForceReinstall $false

#Stage and extract our MSIX package (in the same location as our input MSIX) so we can apply fixups
New-AlkanePSFStagedPackage

#copy new icons to assets folder
Copy-Item "C:\Alkane\NewIcons\*" "C:\Appsource\Staged\Assets"

#Regenerate resources
New-AlkanePSFResourcesPRI 

#replace icon name in AppxManifest
Add-AlkanePSFStringReplace -FindRegex "Assets\\OLDSHORTCUTNAME-" -ReplaceString "Assets\NEWSHORTCUTNAME-"

#Generate config and update manifest
Set-AlkanePSF -OpenConfigJson $false

#Compile and sign
New-AlkanePSFMSIX

MSIX Application Packaging Services

You’d be forgiven for being confused when it comes to Microsoft application packaging and installation frameworks.  It’s a constantly evolving landscape of emerging technologies, with various name changes along the way!

This blog provides a brief history of application packaging and installation frameworks, taking us from setup.exe to MSIX application packaging services.

InstallShield Setup.exe

Back in the days of Windows 95, Microsoft endorsed InstallShield as an installation framework for applications.  However these setup.exe installation packages weren’t very intelligent.  They had no real knowledge of other applications that were currently installed and often resulted in conflicts such as DLL hell and, over time, the degradation of the underlying operating system commonly referred to as ‘winrot’.

The total cost of ownership (TCO) for each device was relatively high, since these conflicts frequently required debugging or ultimately desktop rebuilds.

Windows Installer (MSI)

This led to the introduction of Microsoft Installer (MSI – now known as Windows Installer), which provided more resiliency in the form of rollback, self healing, self repair, dynamic link library (DLL) reference counting and much more.

If authored by a competent application packager, MSI provided a highly reliable installation framework and still does.  The big problem was that many application packagers weren’t (and still aren’t) competent.  They don’t understand how each table in the MSI relational database works, or about COM registration, or about the plethora of Custom Actions available, and a host of other things.  The complexity of authoring bullet proof MSI packages is a steep learning curve for most.

Microsoft ClickOnce

Microsoft introduced ClickOnce as part of the .Net 2 framework, aimed at reducing application conflicts by installing self-contained and self-updating applications.  These  deployments enabled non-administrative users to install them and granted only those users code access security (CAS) permissions necessary for the application.  But there were limitations which prevented ClickOnce applications from installing new fonts, installing files to the Global Assembly Cache (GAC) and writing registry changes.

Microsoft App-V 4.x

Microsoft App-V 4, formerly Softricity Softgrid, overcame ClickOnce technological limitations and eliminated conflict issues associated with setup.exe and MSI by providing isolation against other applications and the underlying operating system.  This meant that junk cleaning and conflict checking was no longer as important.  But due to this level of isolation and the new file format (which streamed in blocks rather than files), there were inherent technological limitations such as the inability to natively package device drivers and a package size limitation of 4gb.

Microsoft App-V 5.x

Microsoft then developed App-V 5.  This was a complete rewrite of the App-V 4 technology by doing away with the SFT file system and introducing an NTFS file system and ‘real’ registry.  The package format also adopted principles of the Open Package Specification (OPC), which is essentially a set of standards to store binary data and XML metadata in a single entity leveraging Open XML and ZIP formats.

App-V 5 had (and still has) a very high success rate when packaging Win32 applications (your common desktop applications) and resolved some of the issues associated with App-V 4 such as the 4gb package size limitation.  However once again, due to being a virtualised package format it still inherited some of the same limitations associated App-V 4.6 such as an inability to package kernel-mode device drivers.

Universal Windows Platform (UWP)

Meanwhile user requirements were beginning to change.  Users needed to access applications on mobile devices in a touch-friendly way.  So Microsoft introduced Universal Windows Platform (UWP) applications (formerly ‘Windows Store’ app or ‘Metro’ app) based on the Appx file format (which also adopts principles of the OPC).  These applications are delivered via the Windows Store (which is now called the Microsoft Store).  But alas, the UWP packaging format didn’t place nicely with traditional Win32 applications and developers were reluctant to rewrite their software just to accommodate UWP.

MSIX Application Packaging Services

In 2018 Microsoft announced a new package format called MSIX – an attempt to create a unified packaging format by combining the best features of MSI, Appx (UWP apps), App-V, and ClickOnce.

Unlike UWP, MSIX supports the packaging of Win32 applications as well as WPF and Windows Forms applications.  And similarly to Appx and App-V, the .MSIX file format is also based on the OPC specification (as such the file extension can be renamed to .zip and extracted using your zip compression tool of choice).

As an added layer of security, it is now a requirement to sign every MSIX package with a valid code-signing certificate.  This means that since the applications are trusted they can be installed from the web, from the Microsoft Store, via SCCM or otherwise.

Microsoft also claims that MSIX provides very reliable installations, clean uninstalls, seamless updates, with optimised network bandwidth and disk space usage.  They also promote a simple transition from your existing application packaging format to the new MSIX format.

There are also some nice new features such as exposure to a wealth of APIs to accomplish things like sending push notifications, and the emergence of MSIX app attach which utilises the VHD file format to perform application layering!

However in its current state, and even though App-V 5 is no longer being actively developed,  MSIX is still not ready for enterprise production environments.

There is still no support for device driver installations.  There is no way for multiple separate MSIX packages to interact with each other like we saw previously with dynamic suite composition (DSC) and connection groups (CG).  There is no native support for MSIX shortcuts that pass command line arguments to the executable.  And no doubt there will be a plethora of other bugs on the horizon that require remediation. (Update – we have developed a Free MSIX Packaging Tool to provide “fixups” via the Package Support Framework)

We will keep a close eye on the evolution of MSIX technology.  But in the mean time please get in touch should you have any application packaging enquiries.