How to deal with these xbf files in the final msix distribution pakcage

[shelllet]

I don't really care about these xbf files, but the names of these files are the same as the original xaml file names , i am very depressed.

[riverar]

Your XAML was compiled down to XAML Binary Format (XBF). What's the issue here?

[shelllet]

how to merge these files or hide the name of xbf files, or randomize these file names.

[shelllet]

To be honest，I don't want to expose these private file names to end user.

[maxkatz6]

End user does not care. Hacker could get these names anyway easily (since it's clr app).

[wjk]

From my perspective the issue here is that the loose XBF files look unprofessional. In my projects, I try my hardest to never have string, image, or other resources as loose files in the file system. They should all go either into a PRI file, or if that's impossible into the resource section in my DLL (RC file for C++, RESX for .NET). The build system not packing the XBF files into a PRI file (and writing out code-behind logic that will cause the app to crash if the XBF files are packed by hand) is a common pitfall I run into all the time. The PRI packing code is very complex and also not open-source, which makes tracking down the reason why the XBF files aren't being packed almost impossible. I think @shelllet is complaining that the XBF files have not been packed into a PRI file properly.

Also, please be aware that even if the XBF files are shipped only inside a PRI file, the makepri.exe dump command can still retrieve their names. At higher verbosity levels, it will also dump their content as Base64 strings. Even though the XBF format is currently not documented anywhere due to the XBF compiler being closed-source, this will change eventually, either due to the compiler source being released, or someone reverse-engineering the file format the hard way. (Empty promises notwithstanding, there has been no indication that WinUI will ever be open-sourced.)

Finally, if you are interested in making it hard for users to decompile your C# program once it has been shipped, try NativeAOT. Any obfuscation of the compiled MSIL can be undone (usually quite easily), and risks false positives from malware scanners. NativeAOT, on the other hand, removes the compiled MSIL from the binary completely. Any would-be reverse engineers would then have exactly the same information to help them as if your program was written in C++, meaning not much. (Of course, any code can be reverse-engineered given enough time and effort. The goal here is to make doing so hard enough that your adversaries get frustrated and give up. Pure C++ binaries are the easiest way to create such a program on the Windows platform; NativeAOT, a close second.) Hope this helps!

[riverar]

I think the core question here (and potentially a candidate for an issue) is: Why aren't these in the PRI? This does indeed look like a mistake.

[shelllet]

Yeah! Many of these xbf files that display business logic look very unprofessional. Is this Microsoft's style? Is this a style that all developers like?

[seven-mile]

When dealing with the recently-released unpackaged WinUI3 apps, this "mistake" is getting worse. You have to release your app with these loose critical UI files. If users miss some of them, they even can't find out why the app doesn't work anymore suddenly.

Implementing embeding xbf seems not quite difficult for MS. I think it's necessary to convert this discussion into an issue?

[seven-mile]

As a workaround, I think I've done it with custom MSBuild Target script. Using the similar method from #348, I inspected MrtCore.PriGen.targets file and find the _LayoutFile ItemGroup can be injected. And then my app works well without loose xbf files.

[seven-mile]

in your .vcxproj

  <Target Name="AddMyEmbeddedItems" BeforeTargets="_GenerateProjectPriFileCore" AfterTargets="_CalculateInputsForGenerateProjectPriFileCore">
    <ItemGroup>
      <MyXamlEmbededItems Include="@(_LayoutFile)" Condition="'%(Extension)' == '.xbf' or '%(Extension)' == '.xaml'" />
    </ItemGroup>
    <Copy SourceFiles="@(MyXamlEmbededItems)" DestinationFiles="@(MyXamlEmbededItems->'$(IntermediateOutputPath)embed\%(RecursiveDir)%(Filename)%(Extension)')" SkipUnchangedFiles="true" />
    <ReadLinesFromFile File="$(_EmbedFileResfilePath)">
      <Output TaskParameter="Lines" ItemName="ItemsFromFile" />
    </ReadLinesFromFile>
    <ItemGroup>
      <MyEmbeddedFileList Include="@(ItemsFromFile)" />
      <MyEmbeddedFileList Include="@(MyXamlEmbededItems->'%(Filename)%(Extension)')" />
    </ItemGroup>
    <WriteLinesToFile File="$(_EmbedFileResfilePath)" Lines="@(MyEmbeddedFileList)" Overwrite="true" Encoding="Unicode" />
  </Target>

[shelllet]

Very excited ,My XBF files are quickly reaching 100+..

[MikeHillberg]

@RealTommyKlein

[RealTommyKlein]

AFAICT, Windows App SDK 1.0's .wapproj packaging project template Blank App, Packaged with Windows Application Packaging Project (WinUI 3 in Desktop) still deploys loose xbfs. But the single-project MSIX projects (Blank App, Packaged (WinUI 3 in Desktop) project template) embeds the xbfs into resources.pri, so they aren't loosely packaged/obviously visible. That being said, like other assets, the embedded xbf file names would still be visible by dumping the resources.pri - sounds like the ask is more for some kind of file name obfuscation, so end-users don't have insight into the business logic of the app? Adding @evelynwu-msft in case she has any other context.

[ghost]

might be related to : #1674

[rohanp-msft]

might be related to : #1674

The two issues are unrelated. Please see my comment in the referenced issue. Thanks to @evelynwu-msft for the help.