Libraries should not merge PRIs from references into their own PRI #4124
Conversation
This file contains 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
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Scottj1s
approved these changes
Jan 30, 2024
bpulliam
approved these changes
Jan 31, 2024
evelynwu-msft
deleted the
user/evelynwu/fix-pri-generation-for-libraries
branch
# for free
to join this conversation on GitHub.
Already have an account?
# 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.
(Addresses microsoft/microsoft-ui-xaml#8857)
The MRT Core targets are incorrectly merging the PRIs of references into the final PRI in all cases. Suppose you have Package A which contains some WinUI controls, which results in some XBFs being inserted as resources into its PRI. There is also a Package B that relies on Package A version 1.0. Finally, there is an App C that relies on both Package A (version 1.1) and Package B. Because Package B is including the PRI resources from Package A version 1.0 in its own PRI, when App C attempts to merge the PRI resources from all of its dependencies a conflict will arise and break the build.
Package B should not be including the PRI resources from Package A in its own PRI, and instead should advertise the dependency and allow App C to resolve it and perform the PRI resource merge itself. In the UWP targets, this was done by checking to see if the project was producing a package but since Windows App SDK needs to also handle unpackaged apps, the correct way to achieve the same goal is to check if the project is a library (i.e. not producing an executable) and not merge PRI resources from dependencies if that is the case.
Note: Libraries (including Nuget packages) affected by this bug will need to be recompiled.