Overview

Apps built with the Windows App SDK should have competitive disk footprint with other frameworks and platforms.

.NET apps that use the Windows App SDK implicitly depend on several large binaries:

• Microsoft.Windows.SDK.NET.dll which is pulled in when setting the TFM to a Windows-specific version
• Microsoft.WinUI.dll which represents WinUI 3
• C#/WinRT projection assemblies
• .NET runtime binaries when self-contained

This disk footprint is inherited whether you use APIs in these binaries or not, which can inflate even new projects to unreasonable levels relative to other frameworks. The cost is amplified when apps are published ReadyToRun which includes both IL and native code versions of the assemblies.

IL trimming is a feature of .NET that can remove or trim unused code from applications, drastically reducing their disk footprint. This is not supported currently due to gaps in WinUI and C#/WinRT, so apps must pay the full disk footprint cost.

The MAUI team did some analysis with IL trimming and found that their self-contained dotnet new maui template without trimming has an installation size of 111MB, while the same template with trimming has an installation size of only 63MB. ReadyToRun inflates the untrimmed template to 155MB, while ReadyToRun with trimming results in 118MB. When you consider the untrimmed disk footprint will be carried by every MAUI application on Windows, you can see the impact not trimming can have on Windows fundamentals. MAUI also trims on other platforms already, so not trimming is a competitive disadvantage on Windows.

Furthermore, IL trimming is a prerequisite for NativeAOT which is .NET 7's ahead-of-time compilation solution. NativeAOT boosts startup and runtime performance by compiling code ahead-of-time (compared to just-in-time with JIT) and is the expected replacement for .NET Native from UWP. Apps migrating from UWP/.NET Native to .NET 6 JIT have reported 2x degradation in startup performance in some cases. NativeAOT should mitigate those issues.

We should support IL trimming for the disk footprint benefits it brings as well as the runtime performance benefits it would enable via NativeAOT.

Developer Experience

The developer experience for enabling trimming should align with https://docs.microsoft.com/en-us/dotnet/core/deploying/trimming/trim-self-contained. As of WinAppSDK 1.1, we do not yet support dotnet publish or the Publish... dialog, but we do support setting related properties in publish profiles (e.g. SelfContained). The minimum bar is that we support setting <PublishTrimmed>true</PublishTrimmed> in publish profiles. We should also strive to support dotnet publish and the Publish... dialog for a more consistent and flexible developer experience.

The .NET model today requires apps be self-contained to participate in IL trimming. In an ideal world, though, apps could choose to be framework-dependent on .NET while trimming out unused code from other binaries. In terms of .NET runtime libraries, a framework-dependent app will always have a lower disk footprint than a trimmed self-contained app.

Deliverables

• https://task.ms/33320463 (C#/WinRT)
• https://task.ms/35181693 (WinUI)