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.