What is Package Identity and how does Windows use it?

What is Package Identity?

When we talk about package identity in Windows applications, we can think of a set of attributes that help the system identify an application package. This is essential for installation, uninstallation, updating, versioning, access to Windows features such as notifications, and distribution through the Microsoft Store.

If we think about it, this is roughly equivalent to Product Code in MSI technology, which helped us identify if a certain package is installed on the system, but the logic and complexity behind it have changed slightly with the new MSIX technology.

Unlike MSI, where the ProductCode was a randomly generated string, Package Identity has some rules attached to it and is made out of several fields defined in the application manifest.

Together, these fields form the package ID, also known as the identity package. The identity has 5 parts:

• Name
• Version
• Architecture
• ResourceId
• Publisher

To be clear, this is automatically constructed during the package build process, whether you are packaging your application with Advanced Installer or Microsoft’s MSIX Packaging Tool.

What is important to understand is that this is the way this is constructed because the package identity is important if you want to distribute further updates to your application.

This means that once you choose a name, architecture, and publisher for your application, you must stick with them in order to further deploy any type of update to your application.

As mentioned above, these are all found in the package appxmanifest, which can be found within any type of MSIX application. If we open one, we should see a section similar to this:

<Identity
    Name="Contoso.TextEditor"
    Publisher="CN=Contoso Corporation"
    Version="1.0.0.0"
    ProcessorArchitecture="x64" />

This means that the application’s identity will become this:

Contoso.TextEditor_1.0.0.0_x64__ContosoCorporation

However, when you run any cmdlet on the system, the most likely package identity that will be returned is:

Contoso.TextEditor_1.0.0.0_x64__8wekyb3d8bbwe

As you can see, instead of ContosoCorporation, we have 8wekyb3d8bbwe, which is the PublisherID.

The PublisherID is generated once a package is digitally signed with a certificate. However, we must proceed with caution because changing the certificate will result in a change in the PublisherID.

Creating a Package Identity

As mentioned in the beginning, there are two ways for your application’s identity to be determined. The first and most obvious solution is to switch your packaging technology to MSIX, Microsoft’s new desired technology.

This would imply either exporting your MSIX for development purposes or, if you are an IT Professional, to convert the application through repackaging.

Both scenarios have their solutions:

• If you are a developer: Visual Studio allows you to create a new Windows Application Packaging Project, which will automatically create the necessary MSIX structure, appxmanifest, and so on.
• If you are an IT Professional: You can convert the package by using either Advanced Installer or MSIX Packaging Tool. MSIX packages will not install unless they are digitally signed. Digital signatures have become mandatory in the software packaging industry.

The second option is to add a Sparse Package with your installer.

Sparse packages are a lightweight Windows package that gives a classic Win32 application a package identity without forcing the developers or IT Professionals to fully package the application to an MSIX. So this is simply just a “ghost MSIX” that contains only metadata rather than the application itself.

You only have the appxmanifest and a digital signature on the inside. After installation, the Win32 app will remain on disk as it did before (for example, C:\Program Files\etc), but Windows will treat it as if it were a packaged app in terms of identity-based features.

As previously mentioned, the Sparse package contains only the appxmanifest, a digital signature, and optionally some visual assets such as icons, logos, etc.

Within the appxmanifest, you basically point the Sparse package to the external executable, which is the actual executable of your main Win32 application.

<Application Id="App"
             Executable="C:\Path\To\YourApp.exe"
             EntryPoint="Windows.FullTrustApplication" />

This entry informs Windows of the following: this package identity belongs to that executable; when the user launches the package, run that executable; and if the executable uses any Windows APIs, such as notifications, please use this identity.

Sparse packages essentially unlock modern Windows features for traditional applications, including toast notifications, file associations, protocol activation, Windows app SDK APIs, shell extensions, background tasks, and declarative capabilities.

Notepad++ is a popular application that uses Sparse packages. This allows Notepad++ to perform the actions it did in the past, such as:

• Show toast notifications
• Integration with Action Center
• Modernize file associations
• When you right-click a compatible extension, it should first appear as a shell extension.

Conclusion

Package Identity is the backbone of the modern Windows app model, which provides applications with a consistent way to be recognized, updated, and integrated across the OS.

MSIX and Sparse Packages help modern and legacy software to include identity-based features such as notifications, protocol handling, and file associations, which are not typically available in traditional Win32 apps.

Sparse packages, as used by apps such as Notepad++, show how effective this approach is, allowing older applications to gain modern Windows functionality without a full migration.