XBF files are copied to MSIX even though already embedded in PRI file when referencing library project

[whiskhub]

Describe the bug

When referencing a WinUI 3 class library containing XAML files in a WinUI 3 app, the resulting binary XAML files (xbf) are being packaged in the MSIX package, even though the files are already embedded in the pri file of the class library:

└── WinUI3_Xbf_Repro/
    ├── AppxBlockMap.xml
    ├── AppxManifest.xml
    ├── ClassLibrary1.dll
    ├── ClassLibrary1.pri  <--- already embeds XBFs
    ├── resources.pri
    ├── WinUI3_Xbf_Repro.dll
    ├── WinUI3_Xbf_Repro.exe
    ├── ...
    └── ClassLibrary1/
        ├── ResourceDictionary1.xbf  <--- unnecessary
        ├── ResourceDictionary2.xbf  <--- unnecessary
        └── ...

This causes unnecessary files in the MSIX, slowing down installation. Also, the entire folder structure and file paths of XAML files are easily visible for the basic user, which is undesirable. (It's clear that the app can be decompiled easily anyways).

Calling makepri.exe dump /if ClassLibrary1.pri also confirms the xbf files are really embedded:

<PriInfo>
	<ResourceMap name="ClassLibrary1" version="1.0" primary="true">
		<Qualifiers/>
		<ResourceMapSubtree name="Files">
			<ResourceMapSubtree name="ClassLibrary1">
				<NamedResource name="ResourceDictionary1.xbf" uri="ms-resource://ClassLibrary1/Files/ClassLibrary1/ResourceDictionary1.xbf">
					<Candidate type="EmbeddedData">
						<Base64Value>[Embedded Binary Data]</Base64Value>
					</Candidate>
				</NamedResource>
				<NamedResource name="ResourceDictionary2.xbf" uri="ms-resource://ClassLibrary1/Files/ClassLibrary1/ResourceDictionary2.xbf">
					<Candidate type="EmbeddedData">
						<Base64Value>[Embedded Binary Data]</Base64Value>
					</Candidate>
				</NamedResource>

Steps to reproduce the bug

Simple repro: https://github.com/whiskhub/WinUI3_Xbf_Repro

1. Create blank WinUI 3 app
2. Add blank WinUI 3 class library project to the solution
3. Reference the library in the main app
4. Add XAML files to the library project
5. Build and compile the app
6. In Visual Studio, select "Release" configuration
7. In Visual Studio, use Package and Publish -> Create App Packages... to create a MSIX package for sideloading
8. Sideload the MSIX file OR simply open it in a ZIP file viewer

The MSIX will contain a subfolder "ClassLibrary1" with a .xbf file for each XAML file in code. The MSIX will also contain a ClassLibrary1.pri file, which already contains the *.xbf file contents embedded.

Expected behavior

There are no *.xbf files in the MSIX output, as they are embedded in the .pri file already.

Screenshots

No response

NuGet package version

WinUI 3 - Windows App SDK 1.6.3: 1.6.241114003

Windows version

Windows 11 (24H2): Build 26100

Additional context

Specifying <DisableEmbeddedXbf>false</DisableEmbeddedXbf> did not make any difference.

[whiskhub]

Still reproducible with Windows App SDK 1.8.250702007-experimental4 and Microsoft.Windows.SDK.BuildTools.MSIX 1.7.20250728.1

[vgromfeld]

Looking at how MSBuild is adding the XBF files, we come up with this not-very-pretty solution on our side.
We've added the following fragment in our library project file to prevent MSBuild from adding the XBF (and XAML file) when building our application:

  <!-- 
    The "AddProcessedXamlFilesToCopyLocal" target(1) is adding the CopyToOutputDirectory=PreserveNewest attribute on all the generated XAML and XBF files of the library.
    This means that the "_CopyOutOfDateSourceItemsToOutputDirectory" target triggered by "_CopySourceItemsToOutputDirectory"(2) is copying all those generated files to the output directory and then into our MSIX package
    The XAML files are not needed in the package since they are compiled into the XBF files. The XBF files are also not needed in the package since they are embedded into the pri files.
    
    (1) defined in C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\Microsoft.Windows.UI.Xaml.Common.Targets
    (2) defined in C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets
  -->
  <Target Name="RemoveXamlAndXbfFilesFromLocalCopy" AfterTargets="AddProcessedXamlFilesToCopyLocal" Condition="'$(BuildingInsideVisualStudio)' != 'true'">
    <ItemGroup>
      <_xamlFileItemsToRemoveFromAllChild Include="@(_AllChildProjectItemsWithTargetPath)" Condition="'%(Extension)' == '.xaml' OR '%(Extension)' == '.xbf'">
        <CopyToOutputDirectory>Never</CopyToOutputDirectory>
      </_xamlFileItemsToRemoveFromAllChild>
      
      <_AllChildProjectItemsWithTargetPath Remove="@(_xamlFileItemsToRemoveFromAllChild)" />
      <_AllChildProjectItemsWithTargetPath Include="@(_xamlFileItemsToRemoveFromAllChild)" />

      <Message Text="(RemoveXamlAndXbfFilesFromLocalCopy) _AllChildProjectItemsWithTargetPath == @(_AllChildProjectItemsWithTargetPath)" />
    </ItemGroup>
  </Target>

[RealFileWorks]

It has not been fixed as of today:

• Windows 11
• Visual Studio 2026 18.0.1
• .NET 10
• Microsoft.WindowsAppSDK 1.8.251106002
• Microsoft.Windows.SDK.BuildTools 10.0.26100.7175
• Microsoft.Windows.SDK.BuildTools.MSIX 1.7.20250829.1

To avoid redundant copying of .xaml and .xbf files (excluding duplicate WebView2Loader.dll files),
I use a DLL reference instead of a project reference in the app’s .csproj file:

<ItemGroup Condition="'$(Configuration)' == 'Debug'">
	<ProjectReference Include="..\WinUIClassLibrary\WinUIClassLibrary.csproj" />
</ItemGroup>
<ItemGroup Condition="'$(Configuration)' == 'Release'">
	<PackageReference Include="Referenced Package of WinUI Class Library" />
	<Reference Include="WinUIClassLibrary">
		<HintPath>..\WinUIClassLibrary\bin\$(Platform)\$(Configuration)\$(TargetFramework)\WinUIClassLibrary.dll</HintPath>
	</Reference>
</ItemGroup>