microsoft / microsoft/WindowsAppSDK

MakePri PRI277 "Conflicting values" on framework resources during multi-project MAUI publish with WindowsAppSDKSelfContained=true (1.8.x and 2.0.1)

Open
#6,439 0 comments 2 reactions 1 assignee View on GitHub

@guimafelipe is already working on this.

Since Apr 30, 2026.

area-SelfContained
Dominant language
C++
Stars
4.7k
Forks
471
Avg merge
3d 13h
Merged PRs (30d)
28

Description

Summary

dotnet publish of a .NET MAUI 10.0.60 head app with -p:WindowsAppSDKSelfContained=true -p:RuntimeIdentifier=win-x64 and ProjectReferences to multiple MAUI class library projects fails with WINAPPSDKGENERATEPROJECTPRIFILE errors. Behaviour is the same on WindowsAppSDK 1.8.251106002, 1.8.260416003, and 2.0.1, despite the 2.0 release notes claiming "improved error handling of scenarios where WindowsAppSDKSelfContained is enabled for class libraries."

There appear to be two related-but-distinct failures depending on whether referenced library projects emit their .pri at the RID-suffixed output path:

  • Default library output path (bin/<tfm>/<lib>.pri, no <rid> subfolder): MakePri fails with PRI252 — "File <lib>.pri not found" — because it looks under bin/<tfm>/<rid>/<lib>.pri.
  • RID-suffixed library output path (forced via <RuntimeIdentifier> defaulted in Directory.Build.props): PRI252 clears, but MakePri then fails with PRI277 — "Conflicting values for resource <framework-resource>" — when aggregating per-library PRIs.
Environment
Component Version
Microsoft.WindowsAppSDK 2.0.1 (also reproduced: 1.8.251106002, 1.8.260416003)
Microsoft.Maui.Controls / .Compatibility / .Graphics 10.0.60 (also reproduced: 10.0.51)
.NET SDK 10.0.101 (build agent), 10.0.202 (local repro pin)
TargetFramework net10.0-windows10.0.20348.0
Configuration Release
RuntimeIdentifier win-x64
OS (build agent) Windows (Azure DevOps)
Multi-project layout 1 head Exe (MAUI app) + ProjectReferences to MAUI class library projects (most <UseMaui>true</UseMaui> with XAML pages); minimal repro uses 3 libraries, original failing repo has ~10
Publish command
dotnet publish `
  --framework net10.0-windows10.0.20348.0 `
  -c Release `
  --no-restore `
  -p:SelfContained=true `
  -p:WindowsAppSDKSelfContained=true `
  -p:PublishReadyToRun=false `
  -p:ArchiveOnBuild=true `
  -p:RuntimeIdentifier=win-x64 `
  -p:Platform=x64 `
  -p:UseMonoRuntime=false `
  -p:AppxBundlePlatforms=x64 `
  -p:AppxBundle=Always `
  -p:AppxPackageSigningEnabled=true
Repro: PRI252 (default library output path)

With no <RuntimeIdentifier> set on referenced library projects, library outputs land at bin/x64/Release/net10.0-windows10.0.20348.0/<lib>.dll (no win-x64 subfolder). The head app builds at bin/x64/Release/net10.0-windows10.0.20348.0/win-x64/<head>.dll. MakePri then fails:

WINAPPSDKGENERATEPROJECTPRIFILE : error : PRI175: 0x80070002 - Processing Resources failed with error: The system cannot find the file specified.
WINAPPSDKGENERATEPROJECTPRIFILE : error : PRI252: 0xdef00071 - File <repo>\Modules\Work\Obzervr.Mobile.Modules.Work.UI\bin\x64\Release\net10.0-windows10.0.20348.0\win-x64\Obzervr.Mobile.Modules.Work.UI.pri not found.
Repro: PRI277 (RID-suffixed library output path)

Adding a default RuntimeIdentifier=win-x64 for Windows-TFM library projects in Directory.Build.props:

<PropertyGroup Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'windows'">
    <RuntimeIdentifier Condition="'$(RuntimeIdentifier)' == ''">win-x64</RuntimeIdentifier>
</PropertyGroup>

This moves library output to bin/x64/Release/net10.0-windows10.0.20348.0/win-x64/<lib>.dll where MakePri expects it. PRI252 clears. MakePri then fails on aggregation:

On WindowsAppSDK 1.8.260416003:

WINAPPSDKGENERATEPROJECTPRIFILE : error : PRI175: 0x80073b0f - Processing Resources failed with error: Duplicate Entry.
WINAPPSDKGENERATEPROJECTPRIFILE : error : PRI277: 0x80073b0f - Conflicting values for resource 'Files/Microsoft.UI.Xaml/Themes/themeresources.xbf'

On WindowsAppSDK 2.0.1 (same scenario, different framework resource):

WINAPPSDKGENERATEPROJECTPRIFILE : error : PRI175: 0x80073b0f - Processing Resources failed with error: Duplicate Entry.
WINAPPSDKGENERATEPROJECTPRIFILE : error : PRI277: 0x80073b0f - Conflicting values for resource 'Microsoft.UI.Xaml/Resources/TextCommandDescriptionCopy'

The aggregated framework resource's identity changes between WinAppSDK versions but the failure mode is the same: per-library PRIs each contain a copy of WinUI framework resources, and MakePri rejects them as "conflicting" rather than deduplicating identical entries (or, where genuinely different, falling back deterministically).

Expected behaviour

MakePri should aggregate framework resources (those originating from Microsoft.UI.Xaml itself) across multiple library projects without raising a "duplicate entry / conflicting values" error. If the contributing PRIs each contain the same framework resource at the same scale/language qualification, that's identity, not conflict. The 2.0 release-note language ("improved error handling of scenarios where WindowsAppSDKSelfContained is enabled for class libraries") implies this scenario was a known concern; the fix did not land for our setup.

Minimal repro

Public sample: https://github.com/wayne-obz/winappsdk-2.0-multiproject-pri-repro

git clone https://github.com/wayne-obz/winappsdk-2.0-multiproject-pri-repro.git
cd winappsdk-2.0-multiproject-pri-repro
dotnet restore src/PriReproApp/PriReproApp.csproj -p:RuntimeIdentifier=win-x64
dotnet publish src/PriReproApp/PriReproApp.csproj `
  --framework net10.0-windows10.0.20348.0 `
  -c Release --no-restore `
  -p:SelfContained=true -p:WindowsAppSDKSelfContained=true `
  -p:RuntimeIdentifier=win-x64 -p:Platform=x64 `
  -p:UseMonoRuntime=false -p:AppxBundlePlatforms=x64 -p:AppxBundle=Always

Layout: 1 head MAUI app (Exe, packaged MSIX) + 3 ProjectReferenced MAUI class libraries with one ContentPage each. The repo's Directory.Build.props defaults RuntimeIdentifier=win-x64 for Windows-TFM library projects so the sample reproduces the PRI277 path; commenting out that block reproduces PRI252.

Things tried that did NOT resolve the issue
  • WinAppSDK 1.8.251106002 → PRI252 (initial state from MAUI 10.0.51 transitive).
  • WinAppSDK 1.8.260416003 (latest 1.8.x patch) → same PRI252.
  • WinAppSDK 2.0.1 (released 2026-04-29) → same PRI252; with RID-default for libraries, PRI277.
  • MAUI 10.0.51 → 10.0.60 (released same day as WinAppSDK 2.0.1) → no behavioural change.
  • <DefaultLanguage> correction en-Au → en-US (cleared a separate PRI257 warning about no resources for the declared default language; did not affect PRI277).
  • <GenerateProjectPriFile>false</GenerateProjectPriFile> for non-Exe Windows projects → PRI252 still appears (head app's MakePri still expects per-library PRIs).
  • <GenerateLibraryLayout>true</GenerateLibraryLayout> + <EnableDefaultPriItems>false</EnableDefaultPriItems> for non-Exe Windows projects → broke dotnet restore itself with NuGet.targets(196,5): error : Invalid framework identifier ''. Reverted.
  • <RuntimeIdentifierOverride> propagation to library projects (referencing #3337 and #4008 workaround) → no effect when CI doesn't set the override variable.
Working build history (for context)

The same multi-project layout publishes successfully with:

  • MAUI 10.0.20
  • WindowsAppSDK 1.7.250909003
  • Same TFM, same publish flags

Failure was introduced by bumping MAUI to 10.0.51+ (which transitively requires WindowsAppSDK >= 1.8.251106002).

Related issues
  • microsoft/WindowsAppSDK#3337 — RuntimeIdentifier propagation in WinAppSDK build
  • microsoft/WindowsAppSDK#4008 — same area
  • dotnet/maui#22342 — "Processing Resources failed with error: Duplicate Entry" with PRI conflicts (on MAUI side)
  • dotnet/maui#25434 — same class of failure
  • microsoft/microsoft-ui-xaml#10308 — XBF files copied to MSIX even though embedded in PRI when referencing class libraries

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.