Free MSIX Packaging Tool for the Package Support Framework

Posted on March 26, 2024 by Kae

This post provides a free MSIX Packaging tool for the Package Support Framework (PSF), and is hosted in the PowerShell Gallery.

Most of us already know that native MSIX has its limitations (at time of writing) in terms of compatibility with some applications. For example, once we package an application into MSIX format we may find that it has issues finding DLLs, or generates Access Denied warnings amongst other annoying things.

So the folks over at Microsoft created the Package Support Framework (PSF), which was later forked by the great Tim Mangan to include additional functionality. The PSF essentially comprises of an executable which acts as the “PSF launcher”, a bunch of associated DLLs that provide “fix-ups”, and a config.json file which tells the launcher what to fix!

How Does The Package Support Framework Work?

In simple terms, we redirect any problematic shortcuts to the PSF launcher instead of the original executable. The PSF launcher then reads the associated config.json file which tells it what to do in terms of which executable to launch (the original executable) and which fix-ups to apply at runtime.

Why AlkanePSF?

When I originally wrote this (over a year ago), injecting the PSF into an MSIX package manually was a bit laborious and fiddly to say the least. The official MSIX packaging tool GUI didn’t support PSF configurations at the time (if I recall), and amending JSON files is prone to human error. So I created this PowerShell module called AlkanePSF that makes life easy (or easier).

The advantages of this scripted approach are that:

It doesn’t require the MSIX packager. You can extract, inject fix-ups, recompile and sign on-the-fly.
It could be used as part of an automation pipeline to inject fixes into a bunch of packages on a file share, or perhaps at the end of an automated conversion batch.
It supports Tim Mangan’s PSF (which includes fix-ups like the MFR fix-up), which the official MSIX packaging tool doesn’t natively support.
It’s fast when making fix-up modifications and re-retesting packages.

Caveats

Whilst it does support every fix-up type, it doesn’t support every single fix-up configuration.

Assumptions

You’ve already packaged your MSIX, launched it and it doesn’t work.
You might have run some process monitoring, and have an understanding of which fixups you might need to apply. Maybe read the Package Support Framework Overview first.
You have a code signing certificate and a password.
You have a basic understanding of fix-ups. If not, use the links below to understand the different types.

Available Cmdlets

Install-AlkanePSFPrerequisite – Installs Windows SDK/Microsoft PSF/Tim Mangan PSF.

New-AlkanePSFStagedPackage – Extracts/stages MSIX.

Add-AlkanePSFApplication – Adds an application from the AppxManifest.xml to “fix”. This must be called for any application that requires fixing.

Add-AlkanePSFFileRedirectionFixup – Adds a FileRedirectionFixup to the application.

Add-AlkanePSFRegLegacyFixup – Adds a RegLegacyFixup to the application.

Add-AlkanePSFEnvVarFixup – Adds a EnvVarFixup to the application.

Add-AlkanePSFDynamicLibraryFixup – Adds a DynamicLibraryFixup to the application.

Add-AlkanePSFMFRFixup – Adds a MFRFixup to the application (Tim Mangan only).

Add-AlkanePSFTraceFixup – Adds support for the trace module.

Add-AlkanePSFStartScript – Adds a StartScript.

Add-AlkanePSFEndScript – Adds an EndScript.

Set-AlkanePSF – Updates AppxManifest.xml, generates config.json.

New-AlkanePSFMSIX – Compiles and signs new MSIX.

Usage of Free MSIX Packaging Tool for the Package Support Framework

One day I’ll get around to documenting it properly. But until that day comes, there are three things to do:

Copy the script below and paste it into a PowerShell ISE session.
Update the variables inside the TODO1 section
Add your own fixups – I’ve added lots of examples below, so remove what you don’t require and modify the rest.

cls
#********************************************
#********************************************
#START TODO1 : Define variables
#********************************************
#********************************************
#The version of AlkanePSF - always check for the latest version here: https://www.powershellgallery.com/packages/AlkanePSF/
$alkanePSFVersion = "2.0.8"
#Define path to input MSIX that needs fixing
$alkanePathToMSIX ="C:\Alkane\alkane.msix"
#Define path to output MSIX
$alkanePathToFixedMSIX ="C:\Alkane\alkane-fixed.msix"
#Define application architecture (32/64).  This will define which PSF DLLs to copy.
$alkaneAppArchitecture = "32" 
#Define path to code signing certificate
$alkanePathToCertificate  = "C:\Alkane\alkanecertificate.pfx"  
#Define password for code signing certificate (if your password contains $ you'll need to prefix with a backtick `$)   
$alkaneCertificatePassword  = "alkanepassword"  
#Specify the name of Tim Mangan's zip release, listed here: https://github.com/TimMangan/MSIX-PackageSupportFramework
$alkaneTmZipName = "ZipRelease.zip-v2024-1-2.zip"
#********************************************
#********************************************
#END TODO1 : Define variables
#********************************************
#********************************************
#Checking if we need to install module
$foundModule = $false
get-module -Name AlkanePSF | foreach {
$version = [string]$_.Version   
if ($version -ne $alkanePSFVersion) {
write-host "Removing AlkanePSF version $version" 
$_ | Remove-Module -Force
} else {
$foundModule = $true
}
}
if (!($foundModule)) {
write-host "Installing AlkanePSF version $alkanePSFVersion"
Install-Module AlkanePSF -RequiredVersion $alkanePSFVersion -Force
}
#Import module
Import-Module AlkanePSF -RequiredVersion $alkanePSFVersion -Force
#Install prerequisites such as Windows SDK, MS PSF, TM PSF
Install-AlkanePSFPrerequisite -ForceReinstall $false
#Stage and extract our MSIX package so we can apply fixups
New-AlkanePSFStagedPackage
#********************************************
#********************************************
#START TODO2 : Define Fixups
#********************************************
#********************************************
#Add first app for PSF fix with working directory fixup and inPackageContext fixup
Add-AlkanePSFApplication -FixupApplicationId "SAMPLEAPP" -FixupWorkingDirectory "VFS\ProgramFilesX86\Alkane\" -FixupArguments @("-exampleargument") -FixupInPackageContext $true
Add-AlkanePSFTraceFixup -FixupApplicationId "SAMPLEAPP" -FixupTraceMethod "outputDebugString" -FixupWaitForDebugger $false -FixupTraceFunctionEntry $false -FixupTraceCallingModule $true -FixupIgnoreDllLoad $true -FixupTraceLevelProperty "default" -FixupTraceLevelValue "allFailures" -FixupBreakOnProperty "default" -FixupBreakOnValue "allFailures"
#Add env var fixups
Add-AlkanePSFEnvVarFixup -FixupApplicationId "SAMPLEAPP" -FixupVarName "alkaneenv1" -FixupVarValue "alkanevalue1" -FixupVarUseRegistry $true
Add-AlkanePSFEnvVarFixup -FixupApplicationId "SAMPLEAPP" -FixupVarName "alkaneenv2" -FixupVarValue "alkanevalue2" -FixupVarUseRegistry $true
#Add DLL fixups
Add-AlkanePSFDynamicLibraryFixup -FixupApplicationId "SAMPLEAPP" -FixupDllName "alkane1.dll" -FixupDllFilepath "VFS\Alkane\alkane1.dll"
Add-AlkanePSFDynamicLibraryFixup -FixupApplicationId "SAMPLEAPP" -FixupDllName "alkane2.dll" -FixupDllFilepath "VFS\Alkane\alkane2.dll"
#Add reg legacy fixups
Add-AlkanePSFRegLegacyFixup -FixupApplicationId "SAMPLEAPP" -FixupType "FakeDelete" -FixupHive "HKCU" -FixupAccess "FULL2RW" -FixupPatterns@(".+\.exe",".+\.dll")
Add-AlkanePSFRegLegacyFixup -FixupApplicationId "SAMPLEAPP" -FixupType "ModifyKeyAccess" -FixupHive "HKLM" -FixupAccess "Full2MaxAllowed" -FixupPatterns@(".+\.exe",".+\.dll")
#Add MFR fixups (only applies to Tim Mangan PSF)
Add-AlkanePSFMFRFixup -FixupApplicationId "SAMPLEAPP" -FixupType "overrideLocalRedirections" -FixupName "ThisPCDesktopFolder" -FixupMode "Disabled"
Add-AlkanePSFMFRFixup -FixupApplicationId "SAMPLEAPP" -FixupType "overrideLocalRedirections" -FixupName "Personal" -FixupMode "traditional"
#Add file redirection fixups
Add-AlkanePSFFileRedirectionFixup -FixupApplicationId "SAMPLEAPP" -FixupType "packageDriveRelative" -FixupBase "example3" -FixupPatterns @(".+\.log")
Add-AlkanePSFFileRedirectionFixup -FixupApplicationId "SAMPLEAPP" -FixupType "knownFolders" -FixupId "ProgramFilesX64" -FixupBase "example1" -FixupPatterns @(".+\.log")
Add-AlkanePSFFileRedirectionFixup -FixupApplicationId "SAMPLEAPP" -FixupType "packageRelative" -FixupBase "example2" -FixupPatterns @(".+\.log")
Add-AlkanePSFFileRedirectionFixup -FixupApplicationId "SAMPLEAPP" -FixupType "knownFolders" -FixupId "ProgramFilesX64" -FixupBase "example4" -FixupPatterns @(".+\.log")
Add-AlkanePSFFileRedirectionFixup -FixupApplicationId "SAMPLEAPP" -FixupType "packageDriveRelative" -FixupBase "example3" -FixupPatterns @(".+\.log")
#An example of applying dynamic file redirection fixups
$workFolder = (get-item $alkanePathToMSIX).Directory.FullName
$packageName = (get-item $alkanePathToMSIX).Basename
$stagingFolder    = "$workFolder\$($packageName)_Staged" 
$vfsFolder    = "$stagingFolder\VFS"
#find unique directories containing log files
Get-ChildItem -Path $vfsFolder -Recurse  -Include *.log | Select -ExpandProperty DirectoryName -Unique | foreach {
$fullPath = $_.Replace($vfsFolder,"VFS")
Add-AlkanePSFFileRedirectionFixup -FixupApplicationId "SAMPLEAPP" -FixupType "packageDriveRelative" -FixupBase $fullPath -FixupPatterns @(".+\.log")
}
#add scripts to run at start and end
Add-AlkanePSFStartScript -FixupApplicationId "SAMPLEAPP" -FixupScriptPath "VFS\ProgramFilesX86\Alkane\example.exe" -FixupScriptArguments @("-install","-allusers") -FixupRunInVirtualEnvironment $true -FixupShowWindow $true -FixupStopOnScriptError $false -FixupWaitForScriptToFinish $true -FixupTimeout 10
Add-AlkanePSFEndScript -FixupApplicationId "SAMPLEAPP" -FixupScriptPath "VFS\ProgramFilesX86\Alkane\example.exe" -FixupScriptArguments @("-install") -FixupRunInVirtualEnvironment $true -FixupShowWindow $true -FixupStopOnScriptError $false -FixupWaitForScriptToFinish $true -FixupTimeout 10
#********************************************
#********************************************
#END TODO2 : Define Fixups
#********************************************
#********************************************
#update AppxManifest.xml, generate config.json
Set-AlkanePSF -FixupPSFType "TM" -FixupOpenConfigJson $false
#Compile staged files into MSIX and sign
New-AlkanePSFMSIX

You can quickly tweak and regenerate your MSIX file to test modifications in a matter of seconds – just re-run the script!

Hint: If you want to view the config.json at the end of each compilation, set -FixupOpenConfigJson $true .

This is work in progress, so your feedback in the comments below is always welcome!

Installing the Package Support Framework (PSF) Using PowerShell

Posted on May 16, 2023 by Kae

This blog provides an example of installing the Package Support Framework (PSF) using PowerShell.

We’ve discussed previously what the Package Support Framework (PSF) for MSIX is, and how we can use it to create fixups for MSIX packages. We also outlined how to manually obtain the PSF files required to fix our MSIX applications. But this post provides a more automated approach of installing PSF for MSIX:

Write-Host "Installing PSF..."
$nuget = get-packagesource | Where-Object ProviderName -eq "Nuget"
if ($nuget -eq $null) {
Register-PackageSource -Name nuget.org -Location https://www.nuget.org/api/v2 -ProviderName NuGet
Install-Package -Name Microsoft.PackageSupportFramework -ProviderName Nuget -Force
} else {
$package = Get-Package | Where-Object Name -eq "Microsoft.PackageSupportFramework"
if ($nuget -eq $null) {
Install-Package -Name Microsoft.PackageSupportFramework -ProviderName Nuget -Force
}
}
$nupkg = Get-Package | Where-Object Name -eq "Microsoft.PackageSupportFramework" | Select -ExpandProperty Source
$psfBinFolder = (get-item $nupkg).Directory.FullName + "\bin\"
write-host "The PSF bin folder is $psfBinFolder"
Write-host "Finished"

MSIX Shortcut Working Directory/Start In

Posted on May 5, 2023 by Kae

MSIX doesn’t natively support shortcut ‘Start In’ working directories, that you would typically see when viewing the properties of an lnk shortcut. This blog explains how we can use the Package Support Framework (PSF) to add an MSIX Shortcut Working Directory/Start In location.

MSIX Shortcut Working Directory/Start In

Sometimes when we launch an application, the shortcut ‘Start In’ location tells the executable where to look for certain files and configurations at runtime. If this value isn’t present (as is the case in MSIX shortcuts) the application will likely throw errors.

To remediate this we can use the Package Support Framework (PSF) to set a working directory/start in location at runtime.

The principle is almost identical to when we added MSIX shortcut arguments/parameters. So in the main you should follow that blog.

The only difference is the contents of the config.json file. Using the previous example linked to above, the original config.json file to provide MSIX shortcut arguments/parameters was:

{
"applications": [
{
"id": "ALKANEAPP",
"executable": "VFS\\ProgramFilesX86\\Alkane\\Alkane.exe", 
"arguments": "-alkaneargument" 
}] 
}

We can amend this to become:

{
"applications": [
{
"id": "ALKANEAPP",
"executable": "VFS\\ProgramFilesX86\\Alkane\\Alkane.exe", 
"arguments": "-alkaneargument",
"workingDirectory": "VFS\\ProgramFilesX86\\Alkane\\"  
}] 
}

You will note the addition of the ‘workingDirectory’ value which points to the directory where Alkane.exe resides. It really is that simple.

MSIX Shortcut Arguments/Parameters

Posted on May 5, 2023 by Kae

MSIX doesn’t natively support shortcut arguments. This blog explains how we can use the Package Support Framework (PSF) to add MSIX shortcut arguments/parameters.

Install the Package Support Framework (PSF)

There are two options to install the PSF for MSIX.

Option 1 – Manually Download PSF for MSIX

Navigate to the Package Support Framework page on Nuget: https://www.nuget.org/packages/Microsoft.PackageSupportFramework/
Click Download Package and you will download a file called something similar to: microsoft.packagesupportframework.[version].nupkg
Rename the extension from nupkg to zip, and extract it.
Navigate to the bin folder and copy all the contents somewhere local. These files form the Package Support Framework and we’ll need some of them later on.

Option 2 – Install PSF for MSIX using Powershell

Follow our post on how to install the Package Support Framework for MSIX using PowerShell.

Add Shortcut Arguments/Parameters To Your MSIX

- - Open your MSIX in edit mode using the MSIX Packaging Tool.
  - Navigate to the Package Information tab and scroll down to the Manifest File section. Click Open File, and it will open the AppxManifest.xml file for your package.
  - In the AppxManifest.xml file will be a node called Applications , and this may contain one or many sub-nodes called Application . This represents all the applications in your package and will look similar to this:
```
<Applications>
<Application Id="ALKANEAPP" Executable="VFS\ProgramFilesX86\Alkane\Alkane.exe" EntryPoint="Windows.FullTrustApplication">
<uap:VisualElements BackgroundColor="transparent" DisplayName="Alkane Solutions" Square150x150Logo="Assets\ALKANEAPP-Square150x150Logo.png" Square44x44Logo="Assets\ALKANEAPP-Square44x44Logo.png" Description="Alkane Solutions">
<uap:DefaultTile Wide310x150Logo="Assets\ALKANEAPP-Wide310x150Logo.png" Square310x310Logo="Assets\ALKANEAPP-Square310x310Logo.png" Square71x71Logo="Assets\ALKANEAPP-Square71x71Logo.png" />
</uap:VisualElements>
<Extensions>
<desktop7:Extension Category="windows.shortcut">
<desktop7:Shortcut File="[{Programs}]\Alkane\Alkane Solutions.lnk" Icon="VFS\ProgramFilesX86\Alkane\App.exe" />
</desktop7:Extension>
</Extensions>
</Application>
</Applications>
```
  - Make a note of the Application Id ALKANEAPP and also the Executable value of VFS\ProgramFilesX86\Alkane\Alkane.exe because we’ll need these values later.
  - Change the Executable value to be PsfLauncher32.exe . We are now telling the package that when the shortcut is clicked we want to launch PsfLauncher32.exe and NOT Alkane.exe . The second line should now look like this:
```
<Application Id="ALKANEAPP" Executable="PsfLauncher32.exe" EntryPoint="Windows.FullTrustApplication">
```
  - Now save the file and close it.
  - We now need to add the PSF files to our package. Navigate to the Package Files tab, right click on the Package folder and click Add file….
  - From your downloaded Package Support Framework (PSF) select the following 6 files (hold down ctrl to select them all) and add them to your package (we don’t need the others, which are related to PSF ‘fixups’):
    - PsfLauncher32.exe
    - PsfRuntime32.dll
    - PsfRunDll32.exe
    - PsfLauncher64.exe
    - PsfRuntime64.dll
    - PsfRunDll64.exe
    Note – we really only need to add the files for our application architecture (NOT our operating system architecture). So if our application was 32-bit and our operating system was 64-bit, we would just add the 3 files containing ’32’.
  - Now we know our package is opening PsfLauncher32.exe, but it doesn’t know what to do with it! So we need to create a file called config.json to tell our package what to do.
  - Open notepad (or Notepad++) and create/save a file called config.json with the following content:
```
{
"applications": [
{
"id": "ALKANEAPP",
"executable": "VFS\\ProgramFilesX86\\Alkane\\Alkane.exe", 
"arguments": "-alkaneargument" 
}] 
}
```
  - You will notice that we have referenced the application ID in the AppxManifest.xml (ALKANEAPP), and we have specified the executable to be the original executable in the AppxManifest.xml (VFS\\ProgramFilesX86\\Alkane\\Alkane.exe). You will also notice that for valid JSON we either need to escape backslashes with another backslash (\\) or we need to replace them with a forward slash. Finally you will notice that we are passing in an argument of -alkaneargument .
  - We now need to add the config.json to our package. Navigate to the Package Files tab, right click on the Package folder and click Add file….
  - Add the config.json file, which should sit alongside the PSF files you added earlier.
  - Save your package and test it.

We have essentially told our MSIX shortcut to launch PsfLauncher32.exe from the shortcut. PsfLauncher32.exe will then read the config.json file and subsequently launch VFS\\ProgramFilesX86\\Alkane\\Alkane.exe with an argument of -alkaneargument.

What is MSIX and What Are The Advantages and Disadvantages of MSIX?

Posted on May 3, 2023 by Kae

As enterprises start to investigate the feasibility of migrating applications to the MSIX format, it’s prudent to know what is MSIX and what are the advantages and disadvantages of MSIX?

MSIX is a modern packaging format designed to simplify and streamline the process of distributing Windows applications. It was introduced by Microsoft in 2018 as a successor to the traditional MSI (Windows Installer) format.

MSIX offers several benefits over MSI, including improved reliability, simplified deployment, and better security. It uses the same underlying technology as the Windows Store to provide a sandboxed environment for applications, which helps to prevent conflicts and improve system stability.

One of the key advantages of MSIX is its ability to handle dependencies and updates more efficiently. With MSIX, applications can be updated automatically in the background, without the need for user intervention. This helps to ensure that users always have the latest version of an application and reduces the burden on IT staff who might otherwise need to manage updates manually.

MSIX also includes support for modern deployment technologies, such as containerization, which can help to further improve reliability and security. Overall, MSIX is a significant step forward in the world of application packaging and is quickly gaining popularity among developers and IT professionals.

MSIX Advantages and Disadvantages

MSIX offers several advantages over traditional installation methods, but there are also a few potential disadvantages to consider. Here are some of the key advantages and disadvantages of MSIX:

Advantages:

Improved reliability: MSIX uses a containerisation approach, which helps to ensure that applications don’t interfere with other parts of the system. This can improve overall system stability and reduce the risk of application conflicts.
Simplified deployment: MSIX packages are self-contained and can be easily distributed and installed without the need for complex scripts or installer packages. This can simplify the deployment process for IT administrators and reduce the likelihood of deployment errors.
Better security: MSIX packages are digitally signed and can include security policies and controls to help prevent malware and other security threats.
Automatic updates: MSIX includes support for automatic updates, which can help ensure that users always have the latest version of an application.

Disadvantages:

Limited backward compatibility: MSIX is only supported on Windows 10 version 1709 and later, so applications packaged in MSIX format may not work on older versions of Windows.
Limited tooling: While Microsoft provides tools for creating and deploying MSIX packages, the ecosystem around MSIX is still relatively new, and some third-party tools and services may not support it yet.
Complex packaging process: Creating an MSIX package can be more complex than traditional installation methods, particularly if the application has complex dependencies or requires custom installation scripts.
Limited customization: MSIX packages are designed to be self-contained, which can limit the ability to customize the installation process or include custom scripts or configurations.

Is MSIX Ready for the Enterprise?

MSIX is becoming increasingly popular in the enterprise space and is considered to be a viable packaging and deployment format for Windows applications. Here are some reasons why MSIX is suitable for the enterprise:

Improved reliability: MSIX’s containerization approach can help improve system stability and reduce the risk of application conflicts, which is especially important in the enterprise where IT administrators need to manage a large number of applications.
Better security: MSIX’s support for digital signatures and security policies can help prevent malware and other security threats, making it a more secure option for enterprise applications.
Simplified deployment: MSIX’s self-contained packages can be easily distributed and installed, reducing the need for complex deployment scripts and making it easier for IT administrators to manage application deployment across a large number of devices.
Automatic updates: MSIX supports automatic updates, which can help ensure that users have the latest version of an application without the need for manual intervention.
Support from Microsoft: Microsoft has been actively promoting MSIX as the future of Windows application packaging, and is investing resources to improve its support for the format.

That being said, there are still some limitations to consider when using MSIX in the enterprise. For example, MSIX is not compatible with older versions of Windows, and some third-party tools and services may not yet fully support the format. Additionally, the complexity of the packaging process may require additional training or expertise for IT administrators who are new to the format.

MSIX Application Packaging Services

Posted on May 29, 2020 by Kae

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.