Fix sparse-packaged apps unable to discover module-specific PRI files#6376
Merged
yeelam-gordon merged 7 commits intomainfrom Apr 9, 2026
Merged
Fix sparse-packaged apps unable to discover module-specific PRI files#6376yeelam-gordon merged 7 commits intomainfrom
yeelam-gordon merged 7 commits intomainfrom
Conversation
Sparse-packaged apps have package identity (via AddPackageByUriAsync) but deploy resources as loose files next to the executable. GetDefaultPriFile() determines isPackaged=true for these apps (since they have identity), causing GetDefaultPriFileForCurentModule to pass "resources.pri" to MrmGetFilePathFromName — which only searches for that exact filename, skipping the [modulename].pri fallback that unpackaged apps receive. When the "resources.pri" search fails for apps with identity, fall back to the unpackaged discovery path (pass nullptr to MrmGetFilePathFromName) which triggers the broader search including "[modulename].pri" derived via PathCchRenameExtension from the process executable name. If the fallback also fails, return the original HRESULT from the "resources.pri" search so callers that check for specific errors (e.g., ERROR_FILE_NOT_FOUND) are not broken. Existing test coverage: - DefaultResourceManagerWithExePri validates the nullptr fallback mechanism - DefaultResourceManager validates error behavior when no PRI exists - DefaultResourceManagerWithResourcePri validates the normal packaged path A full sparse-app integration test requires actual sparse package registration (AddPackageByUriAsync) which is beyond unit test scope. Fixes: microsoft/microsoft-ui-xaml#10856 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
yeelam-gordon
commented
Apr 3, 2026
dev/MRTCore/mrt/Microsoft.Windows.ApplicationModel.Resources/src/Helper.cpp
Outdated
Show resolved
Hide resolved
yeelam-gordon
commented
Apr 3, 2026
dev/MRTCore/mrt/Microsoft.Windows.ApplicationModel.Resources/src/Helper.cpp
Outdated
Show resolved
Hide resolved
yeelam-gordon
commented
Apr 3, 2026
dev/MRTCore/mrt/Microsoft.Windows.ApplicationModel.Resources/src/Helper.cpp
Outdated
Show resolved
Hide resolved
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates MRTCore’s default PRI discovery logic to support sparse-packaged apps (apps with package identity but deploying PRI files as loose files next to the executable), ensuring module-specific PRI files (e.g., [modulename].pri) can be discovered when resources.pri is not present.
Changes:
- After a failed packaged-module lookup (
"resources.pri"), add a fallback to the unpackaged discovery path (MrmGetFilePathFromName(nullptr, ...)) for apps with identity. - Preserve the original HRESULT from the packaged-module lookup when the fallback also fails.
dev/MRTCore/mrt/Microsoft.Windows.ApplicationModel.Resources/src/Helper.cpp
Outdated
Show resolved
Hide resolved
yeelam-gordon
commented
Apr 3, 2026
dev/MRTCore/mrt/Microsoft.Windows.ApplicationModel.Resources/src/Helper.cpp
Show resolved
Hide resolved
dev/MRTCore/mrt/Microsoft.Windows.ApplicationModel.Resources/src/Helper.cpp
Outdated
Show resolved
Hide resolved
yeelam-gordon
commented
Apr 3, 2026
dev/MRTCore/mrt/Microsoft.Windows.ApplicationModel.Resources/src/Helper.cpp
Outdated
Show resolved
Hide resolved
yeelam-gordon
commented
Apr 3, 2026
dev/MRTCore/mrt/Microsoft.Windows.ApplicationModel.Resources/src/Helper.cpp
Outdated
Show resolved
Hide resolved
dev/MRTCore/mrt/Microsoft.Windows.ApplicationModel.Resources/src/Helper.cpp
Outdated
Show resolved
Hide resolved
Contributor
Author
|
@copilot review |
Agent-Logs-Url: https://github.com/microsoft/WindowsAppSDK/sessions/ed36cfc6-52ad-414b-8e1a-dc16f413a97e Co-authored-by: yeelam-gordon <73506701+yeelam-gordon@users.noreply.github.com>
Contributor
Reviewed the current state of |
Contributor
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
dev/MRTCore/mrt/Microsoft.Windows.ApplicationModel.Resources/src/Helper.cpp
Show resolved
Hide resolved
Scottj1s
approved these changes
Apr 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes sparse-packaged apps (unpackaged + self-contained WinUI3 with identity via
AddPackageByUriAsync) failing to locate module-specific PRI files (e.g.,MyApp.priset viaProjectPriFileName).Why This Matters
Not an regression, it doesn't work from the first day.
While unpackaged apps that need package-identity-only APIs (e.g., Windows AI APIs) must use sparse app registration (
AddPackageByUriAsync) to acquire identity. When multiple such apps share the same output directory, each needs its own module-specific PRI (viaProjectPriFileName) to avoid resource conflicts. This fix unblocks that scenario - without it, any sparse-packaged app with a custom PRI name fails to load resources.Problem
GetDefaultPriFile()determinesisPackaged=truefor sparse apps because they have package identity. This causesGetDefaultPriFileForCurentModuleto pass"resources.pri"toMrmGetFilePathFromName, which only searches for that exact filename - skipping the[modulename].prifallback that unpackaged apps (the one leverage sparse app) receive.When multiple apps share the same output directory, each needs its own module-specific PRI to avoid conflicts, but sparse apps could only find
resources.pri.Fix
When the packaged
"resources.pri"search fails for apps with identity, fall back to the unpackaged discovery path (passnullptrtoMrmGetFilePathFromName) which triggers the broader search including"[modulename].pri"derived from the process executable name.The fallback is gated on
IsResourceNotFound(hr)to ensure only genuine not-found conditions trigger it, avoiding masking real errors (e.g.,E_OUTOFMEMORY,E_ACCESSDENIED). If the fallback also fails, the original HRESULT from the"resources.pri"search is returned for backward compatibility so callers checking for specific errors (e.g.,ERROR_FILE_NOT_FOUND) are not broken.Changed file
dev/MRTCore/mrt/Microsoft.Windows.ApplicationModel.Resources/src/Helper.cppExisting test coverage
DefaultResourceManagerWithExePri— validates the nullptr fallback mechanismDefaultResourceManager— validates error behavior when no PRI existsDefaultResourceManagerWithResourcePri— validates the normal packaged pathA full sparse-app integration test requires actual sparse package registration (
AddPackageByUriAsync) which is beyond unit test scope.Validation
Builds clean with no warnings
/azp runpipeline validationA microsoft employee must use /azp run to validate using the pipelines below.
WARNING:
Comments made by azure-pipelines bot maybe inaccurate.
Please see pipeline link to verify that the build is being ran.
For status checks on the main branch, please use TransportPackage-Foundation-PR
(https://microsoft.visualstudio.com/ProjectReunion/_build?definitionId=81063&_a=summary)
and run the build against your PR branch with the default parameters.