Conflicting values for resource Compact.xbf

[JulienTheron]

Describe the bug

I get the following build error if the WinUI package is not consolidated to the same version throughout the solution:
2>GENERATEPROJECTPRIFILE : error : PRI175: 0x80073b0f - Processing Resources failed with error: Entrée en double. (duplicate entry)
2>GENERATEPROJECTPRIFILE : error : PRI277: 0xdef00532 - Conflicting values for resource 'Files/Microsoft.UI.Xaml/DensityStyles/Compact.xbf'

Steps to reproduce the bug

Steps to reproduce the behavior:

1. Build this simple repro project: WinUIConflictRepro.zip.

Expected behavior

I should be able to build a control library targeting a minimum version of WinUI, while the app uses a more recent version.
In other words, if my control library needs 2.4.0, the app should be able to use 2.4.2 or 2.5.0, and not be forced to stick with 2.4.0.

Screenshots

N/A

Version Info

NuGet package version:
[Microsoft.UI.Xaml 2.4.0]
[Microsoft.UI.Xaml 2.4.2]

Windows 10 version	Saw the problem?
Insider Build (xxxxx)
May 2020 Update (19041)	Yes
November 2019 Update (18363)
May 2019 Update (18362)
October 2018 Update (17763)
April 2018 Update (17134)
Fall Creators Update (16299)
Creators Update (15063)

Device form factor	Saw the problem?
Desktop	Yes
Xbox
Surface Hub
IoT

Additional context

Visual Studio Professional 2019 16.6.5
Language: C#

[StephenLPeters]

@kmahone or maybe @jevansaks I think we've discussed this potential issue in the past but I'm having trouble remembering specifics

[StephenLPeters]

@licanhua @kaiguo sounds like you two might have some context on this issue as well?

[kmahone]

This scenario SHOULD work in the case where we are dealing with non-prerelease versions and packages with matching major and minor versions. So WinUI 2.4.0 should be compatible with WinUI 2.4.2, but not with WinUI 2.3.

No prerelease version is compatible with any other prerelease version.

If this issue is occurring when both of the above conditions are true (e.g. with 2.4.0 and 2.4.2), we should investigate to understand the root cause.

[StephenLPeters]

@JulienTheron Can you confirm whether or not you are using 2 different preview winui packages across your app and class library? @kmahone this means that we really not like control libraries or class libraries publish on a preview version huh?

[kmahone]

@kmahone this means that we really not like control libraries or class libraries publish on a preview version huh?

If a control library consumes a prerelease WinUI, then the app using that library would need to use the same prerelease version. The reason for this is that we do not guaranteed api compatibility across prerelease versions. For preview types, we add/remove/rename apis while they are in prerelease.

[licanhua]

His problem is related to framework package other than prerelease.
#1603 created microsoft.ui.xaml.pri, then there are two versions of .pri which is referenced by compiler. It should be Compiler's responsibility to choose one of them. From the description, look like both .pri are unpackaged, then merged and result into conflict.

[JulienTheron]

@StephenLPeters I'm using two different stable packages. 2.4.2 in the app project, 2.4.0 in the control library.

[licanhua]

@JulienTheron You should be able to workaround the this issue by adding below target to WinUIConflictRepro. In my example, 2.4.2 microsoft.ui.xaml.pri file is removed. I can understand the compatibility between 2.4.0 and any 2.4.x, but I don't think mixing 2.4.x and 2.5.x will be supported.

@StephenLPeters , You can start discuss with compiler team who maintains C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\VisualStudio\v16.0\AppxPackage\Microsoft.AppXPackage.Targets. I think the best place to remove duplication is RemoveDuplicatePriFiles, but look like they can't resolve multiple package version which is with the same nuget package id.

  <Target Name="_FixMUXPri" AfterTargets="RemoveDuplicatePriFiles" BeforeTargets="_ComputeInputPriFiles">
    <ItemGroup>
      <MyPriToBeRemoved Include="@(_PriFilesFromPayload)" Condition="'%(_PriFilesFromPayload.NuGetPackageId)' == 'Microsoft.UI.Xaml' and '%(_PriFilesFromPayload.NuGetPackageVersion)' == '2.4.2'" />
      <_PriFilesFromPayload Remove="@(MyPriToBeRemoved)" />
    </ItemGroup>
  </Target>

[licanhua]

Here is the build binlog with the 'conflicts' error.
WinUIConflictRepro_Debug_x86_Build_2020-08-01T21_42_42.2247115-07_00.binlog.zip

[JulienTheron]

@licanhua Thanks for the workaround, but why are you saying that mixing 2.4.x with 2.5.x shouldn't be supported? If 2.5.x only introduces new APIs (maintaining backward compatibility), then it should be the same as with any NuGet package. I should be able to make a library that targets the minimum version needed, and let the application use whichever one it wants (while respecting the minimum version, of course). Am I missing something?

[licanhua]

UI is subject to change from release to release. Some are considered as 'breaking change' from UI aspect, but from API part, it's the same. For example, #1961 proposal changed the space, and it's a break change if you app is very sensitive to the layout.
If the currently official version is 2.4.x, and 2.5.0 is actively under development. then the breaking change will goes to 2.5.0, and 2.4.x only accept bug fix.

[JulienTheron]

Thanks for the explanation. I understand the breaking change from a UI point of view, but that doesn't justify the fact that it doesn't compile. I don't think that's a proper way to inform developers that their UI layout may be misaligned.

[kmahone]

CanHua brings up a good point with regards to changes in layout, etc as a reason why 2.3.x would not be compatible with 2.4.x.

However a more significant reason why this scenario would not work is that the ABI (binary interface) is not maintained across versions of the package with a different major/minor version. The API of a (non-preview) type stays backwards compatible (e.g. apis are only added not removed or changed), which means that source code written for an earlier version will compile against the newer version. But source code compatibility is not enough to guarantee binary compatibility. So a dll compiled against an older version of the package is not guaranteed to work against a newer version without being recompiled.

It might work for C# code (I'm not sure), but I know that it will not work for C++ code.

@JulienTheron were you able to get the scenario to work with 2.4.0 and 2.4.2 using licanhua's proposed work-around? If so, we should try to get a fix into WinUI so that this scenario works out of the box.

[JulienTheron]

I can confirm the workaround is working. But I think we'd like to exclude 2.4.0 pri file, and not 2.4.2 like what's proposed.

[stevenbrix]

This seems problematic for unpackaged apps, which will essentially behave identically to pre-release versions of WinUI2.x.

@JulienTheron what is the expected/desired behavior in this scenario?

[JulienTheron]

@stevenbrix I'm sorry but I'm not following you there. WinUI 2.x is a library for UWP apps. What do you mean by "unpackaged"?

[stevenbrix]

Sorry, I was referring to WinUI3, which will support unpackaged desktop apps.

The way that apps will consume WinUI3 in unpackaged desktop apps will be very similar to how apps consume preview bits of WinUI2.x

[JulienTheron]

Then it will be a nightmare for library authors as they will have to release a new version of their libraries for each release of WinUI 3.
The expected behavior (at least in C#), is to be able to make a library using, say WinUI 2.4, and to have an application use this library with any version of WinUI greater than or equal to 2.4 (as long as the major version is the same).
This is what any .NET developer expects from a NuGet library (which follows semantic versioning).

[stevenbrix]

Then it will be a nightmare for library authors as they will have to release a new version of their libraries for each release of WinUI 3.

No one is forced into this behavior, you can choose to package your app if you like

This is what any .NET developer expects from a NuGet library (which follows semantic versioning).

WinUI stays up to date due to a tech called "Framework Packages", which are an MSIX package. We only use Nuget as a delivery mechanism for this framework package. I think for most Nuget packages, the binaries are copied to the app output and ship with the app, so your dependencies are pinned.

FWIW, there is microsoft/WindowsAppSDK#89, which would allow unpackaged apps to use this tech, but it would still be opt-in.

[aschultz]

I ran into this error with the following project configuration:

• React Native Windows 0.63 (references Microsoft.UI.Xaml.2.3.191129002)
• Custom C++/WinRT library project (references Microsoft.UI.Xaml.2.5.0 and RNW)
• C++/WinRT UWP app project (references Microsoft.UI.Xaml.2.5.0 and the other two projects)

Note here that none of this is pre-built. These are all being built from source as part of one VS solution.

Changing the library and app to use the same WinUI NuGet package (2.3.x) fixed the error.

If this is the expected behavior, I agree with @JulienTheron that it's problematic. In the case of RNW, it means the React Native Windows SDK sets the pace and any time it pulls in a new WinUI version every community package that also uses WinUI will need to publish an update, even if nothing they actually use or expose has changed.

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 5 days.