Package identity exists for one primary purpose:
To provide software with a stable and unambiguous way to identify a package.
This is a considerable improvement over the historical tendency to assign UUIDs and GUIDs to nearly everything – including things that humans were expected to discuss in meetings.
Identity Is for Systems
A package’s Name, Package Full Name, and other identity-derived values are intended for developer and system use.
These identifiers prioritize correctness, uniqueness, and programmatic consumption – not clarity or friendliness from an end-user’s perspective.
Identity must remain stable across servicing operations and dependency resolution. If it changes, the system quite reasonably concludes that it is no longer the same package.
DisplayName Is for Humans
That’s where DisplayName comes in.
People use a package’s display name. You’ll typically see it in Start, Settings, installation experiences, and runtime surfaces.
<Package>
<Identity Name="Contoso.Parts"
Publisher="CN=Contoso LLC, O=Contoso LLC, L=Paris, C=France"
Version="1.2.3.4"
ProcessorArchitecture="x64" />
<Properties>
<DisplayName>Contoso Parts 2026</DisplayName>
...
Unlike package identity fields, which must remain stable for deployment, runtime and servicing, a display name is free to evolve for branding, marketing, or usability reasons.
Identity tells the system what the package is.
The display name tells the user what it’s called.
Localization varies for the same product. As a result, localized values make poor programmatic identifiers. In addition, branding changes usually affect the display name, not the package identity. The package remains the same package even if marketing decides to call it something else.
Localization
Users speak many languages, so hard-coding a single human-readable string would be somewhat limiting.
To support localization, the value of ms-resource:. The runtime resolves the value to a localized string for the user’s language and region.
<DisplayName>ms-resource:PackageDisplayName</DisplayName>
Developers can then provide the referenced as multiple language-specific values in the package.
Users may see different strings based on their localization context – all without altering the package’s underlying identity.
TL;DR
- Package identity is for machines
- Display name is for humans
Confusing the two tends to make at least one of them unhappy – and occasionally both.
Is there a documented way to resolve these ms-resource:* strings (not only a display name) from outside the package (such as from a regular Win32 application)?
This is basically telling the package to look in the PRI resources for a string named DisplayName. This is documented in the app resources documentation.
So the best way to do it would be through the Windows App SDK resource manager interfaces, Microsoft.Windows.ApplicationModel.Resources. These can be used from a regular Windows API application too, but you have to reference the Windows App SDK, and C++/WinRT is the best option for accessing the WinRT API for C++, and CsWinRT for C#.
Ah, yes, indeed. The WinRT interfaces in Windows.ApplicationModel.Resources.Core allow accessing localized strings from other packages as well, nice. I was hoping for something easier to call from pure C (so a regular API or some COM interfaces, as WinRT is a bit annoying to work with on low level). SHLoadIndirectString is a good candidate, but it needs a fully-qualified resource name and I haven’t found a simple way to translate ms-resource:ResourceName to the correct @{PackageFullName?ms-resource://ResourcePath/ResourceName} for a given package. Thanks for the info!
https://learn.microsoft.com/en-us/windows/uwp/app-resources/
There’s also SHLoadIndirectString() if you convert the package’s “ms-resource:boo” to the right format. See the “Package name and resource ID” bullet on the SHLoadIndirectString page