MSIX packaged app has a huge size

[JosHuybrighs]

I am migrating my UWP/DesktopBridge package to a WinAppSDK desktop packaged app (through a WAP project in VS) and so far can only see major advantages of doing this. There is however 1 serious "issue" that concerns me and that is package size.
My current UWP/DesktopBridge app available on the Microsoft Store has a MSIX package that has a size of 40 MBytes.
The WinAppSDK/WinUI3 migrated version with the same functionality has a size of 261 MBytes.

The issue has already been brought up in 2020 for WinUI3 (see #2579) but it remains unclear whether this is something to worry about or not.
I can imagine people looking for an app in the Microsoft Store and seeing a size of +260 MBytes wondering why this is so big.

Is it possible to somehow reduce the size?
Is there somewhere a good description of how we have to understand this and how the Windows system deals with installing these packages. E.g. does it load everything? Is the final footprint after installation less? How does it work when the app was using WinAppSDK 1.3 and gets updated and now uses 1.4?

The big question really is: Is this something we have to be concerned about? Will it hinder deployment/installation?

[DarranRowe]

This isn't actually a universal problem. As a bit of an example, a small WinUI 3 C++ application, fully bundled with all 3 supported platforms is only ~2.5MiB.

This is not an example of a real world application, but this is just to illustrate that this isn't a purely WinUI 3 project problem.

IIRC, the root of this problem is how the C# side of things works. If you look at one of the .pubxml files:

<?xml version="1.0" encoding="utf-8"?>
<!--
https://go.microsoft.com/fwlink/?LinkID=208121.
-->
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <PublishProtocol>FileSystem</PublishProtocol>
    <Platform>x64</Platform>
    <RuntimeIdentifier>win10-x64</RuntimeIdentifier>
    <PublishDir>bin\$(Configuration)\$(TargetFramework)\$(RuntimeIdentifier)\publish\</PublishDir>
    <SelfContained>true</SelfContained>
    <PublishSingleFile>False</PublishSingleFile>
    <PublishReadyToRun Condition="'$(Configuration)' == 'Debug'">False</PublishReadyToRun>
    <PublishReadyToRun Condition="'$(Configuration)' != 'Debug'">True</PublishReadyToRun>
   <!-- 
    See https://github.com/microsoft/CsWinRT/issues/373
    <PublishTrimmed>True</PublishTrimmed>
    -->
  </PropertyGroup>
</Project>

Do you see the SelfContained property? I believe this copies the entire .NET runtime into the package, thus removing the dependency on the system. What's more, the C# projection adds a fair bit more on top of this. This is why .NET Native AOT and IL trimming are sought after.
So, until all of this is fully supported in the Windows App SDK/WinUI 3 libraries, the C# side of things will always have this disadvantage.

[JosHuybrighs]

@DarranRowe Thanks for the prompt reaction.

I think I am starting to understand now what the disadvantage is when the app is written in C# for this framework. Mixed feelings when you are a developer such as I who started in ancient times with assembly language, moved to C and some time later to C++, and finally C#. All with the benefit of improved productivity, better code quality, etc. Looks like C++ is apparently the 'better' approach for WinAppSDK and WinUI.

Anyhow, I started reading the latest release notes for WindowsAppSDK again where is stated that it now should be possible to trim self-contained apps. I will see how this goes although my expectations are low given various other articles mentioning problems with reflection, XAML binding (I haven't used x:Bind everywhere), etc.