WPF is not trim-compatible

[agocke]

At the top-level, WPF apps should be able to use trimming with predictable results. To trim WPF safely, the trim warnings need to be fixed. A list of all warnings and a summary are provided here:

WPF specific warnings can be seen in the file below, usinglinkerwrn3.txt

Warning information can be found here at the mono site.

This sections of the linking design document gives guidance for library developers on how to approach fixing warnings.

The warnings grouping is as below

Warnings	Count
IL2075	89
IL2070	59
IL2026	37
IL2072	25
IL2080	22
IL2094	11
IL2057	10
IL2067	8
IL2077	6
IL2060	5
IL2055	5
IL2090	4
IL2087	2
IL2065	1
IL2091	1
IL2058	1
IL2059	1

Goals

• [ ] WPF template produces zero/minimal trim warnings
• [ ] WPF APIs which are not linker-friendly are correctly annotated

Progress

Information gathering

• [x] Generate list of warnings produced when linking a representative WPF app
• [x] Categorize warnings, sorting to netcore warnings and WPF-specific warnings (see https://github.com/dotnet/runtime/issues/43078)
• [x] Identify the cause of the warnings and propose fixes

Code fixes

• [ ] Fix warnings or annotate APIs as necessary
• [ ] Identify linker-unsafe constructs and propose replacements for functionality

[mateoatr]

Here is the list of all the linker warnings that I get when publishing a wpf app with -p:PublishTrimmed=true and disabling the default --no-warns: https://gist.github.com/mateoatr/596ba43e079a138ac79b907d2974089d

[LakshanF]

WPF specific warnings can be seen in the file below, usinglinkerwrn3.txt

Warning information can be found here at the mono site.

This sections of the linking design document gives guidance for library developers on how to approach fixing warnings.

The warnings grouping is as below

Warnings	Count
IL2075	89
IL2070	59
IL2026	37
IL2072	25
IL2080	22
IL2094	11
IL2057	10
IL2067	8
IL2077	6
IL2060	5
IL2055	5
IL2090	4
IL2087	2
IL2065	1
IL2091	1
IL2058	1
IL2059	1

[Symbai]

The goal for .NET 6 should be to be able to the trim the framework libraries for WPF apps, but not the user code or 3rd party references.

What's the status on this? As of now WPF does not support any trimming in .NET6 and there are only a few months left before .NET6 releases. Is this still targeted for .NET6 or can someone say for sure that it will take longer?

[agocke]

It seems very unlikely this will be done for 6.0.

I'll leave it up to @ryalanms to comment on WPF resourcing/scheduling.

[mansellan]

Is there an update on this? Might it make it into .Net 7.0 ?

[rgwood]

Nobody from the WPF team has responded to this issue. I think it's fair to say that this almost certainly will not happen for .NET 7, and unless the WPF team's resourcing situation changes it will never happen.

[gt5700]

Would it be possible to allow the trimming of WPF if the TrimMode is set to CopyUsed? This way, it would be possible to migrate .Net5 applications to .Net6, as I already have to specify TrimmerRootAssembly. To disable trimming for both "Link" and "CopyUsed" TrimModes in .Net6 gives no option but to almost double the size of my apps.

[ThomasGoulet73]

@gt5700 Trimming WPF applications still works in .Net 6 but you need to add this property to your project to avoid the error on publish: <_SuppressWpfTrimError>true</_SuppressWpfTrimError>. The warning was changed to error in dotnet/sdk#19409 for the .Net 6 SDK. As far as I know, if your application was trimmable in .Net 5 it will also be trimmable in .Net 6 though your mileage may vary because the trimmer could be more aggressive in .Net 6.

[Symbai]

My app was trimmable in .NET5 but switching to .NET 6 broke it. Even if it seems to work you barely can tell as you have to test every single function and any newer .NET version can easily break it. Which means you have zero guarantee. Without official support I wouldn't recommend it for larger or business applications. But like @rgwood said it will very likely never happen. The recently published roadmap shows zero interest in bringing any new features to WPF. WPF will have the same future as .NET Framework. Its not dead but it's dead.

[gt5700]

@ThomasGoulet73 thanks for the tip about <_SuppressWpfTrimError>true</_SuppressWpfTrimError>. I'm assuming the underscore prefix implies this is a somewhat "undocumented" or "internal" switch. A quick search does not return much at all about it. If my assumption is correct, perhaps a more "documented" or "public" switch would give more people a choice about trimming a WPF app. Since it appears official support for WPF trimming is highly unlikely, said "switch" would probably need appropriate warnings. Perhaps the trimmer error message (or the page https://aka.ms/dotnet-illink/wpf) could mention the switches existence.

[kant2002]

Not sure about future. But at least some progress with taking community contribution is happening. It requirest patience, but smallish PRs flowing inside codebase and fixing a bit of trimming issues here and there. It's far from perfect, and I did not expect large-scale improvements. At the same time I would like to say that custom build of WPF is easy to use, and if issue with trimming would be small, I would recommend upstream the fix. Please take into consideration that fix may sit in PRs for a month. So be patient.

[mayurpaghdal]

@kant2002 any updates on this?

[kant2002]

@mayurpaghdal there no progress, so there no update. You should check existing issue.

I think if somebody wants to have trimmable WPF there options to nudge Microsoft, somebody should convince Microsoft that there market for that. You should provide case iltrim for your app, and let MS know. Also please contact your MS representative and try talk to them about feature, so you use 2 communication channels.

Other option probably would be sponsor some for of WPF, that probably would be faster 😉

[tapika]

One approach is always to go with C++, I doubt it would require much trimming at the end, and also depending on UI framework - it could be already portable to multiple OS:s.

https://www.youtube.com/watch?v=vWXrFetSH8w https://medium.com/swlh/what-makes-godot-engine-great-for-advance-gui-applications-b1cfb941df3b

Let me know if someone will try those approaches (interested in how community around those UI's will evolve)

[GeorgeS2019]

@tapika

Let me know if someone will try those approaches (interested in how community around those UI's will evolve)

With Godot4 dotnet6 compiled with MSVC Windows which is c# entry console NativeAOT app, what is needed is to use XAML to create Godot UI

[lindexi]

How about https://github.com/yangzhongke/Zack.DotNetTrimmer ?

Zack.DotNetTrimmer supports Windows Forms and WPF.

[Symbai]

How about https://github.com/yangzhongke/Zack.DotNetTrimmer ?

Yeah for smaller projects it's probably okay, but not everyone has that much time on every publish:

is that it requires you to run the project to be trimmed and run through all the functionality in the program so that you can detect assemblies that will not be used under any circumstances.

We can likely achieve both, trimming and AOT thanks to the community but its the WPF repo owners who are currently blocking every little step by completely ignoring these PRs.

[TheHellTower]

Hello, is there any update on this ?

[GeorgeS2019]

godot 4 c# is closer to this vision than ever before => https://github.com/dotnet/wpf/issues/3811#issuecomment-1128724303

[Qianyiaz]

Tell me they won’t give up on this.

[kant2002]

The only way that "they" do something in Open source project, is to contribute in the direction you want to fix. If WPF trimmability is wanted, please, please contribute to this project toward making this happens. That's really huge amount of work, so please help.

[franchyd]

The only way that "they" do something in Open source project, is to contribute in the direction you want to fix. If WPF trimmability is wanted, please, please contribute to this project toward making this happens. That's really huge amount of work, so please help.

Partially, I think its still on the repo team to actually move on PR's otherwise its wasted effort.

[cdock1029]

The only way that "they" do something in Open source project, is to contribute in the direction you want to fix. If WPF trimmability is wanted, please, please contribute to this project toward making this happens. That's really huge amount of work, so please help.

In "open source"? This is not some poor lowly developer's side project, this is a $3.7 trillion corporate behemoth and their platform upon which many thousands of devs build applications which contribute value back to them. If any entity on the planet does not need free labor to develop features and fix bugs, it would be Microsoft. "They" being the employees paid to work on this or Microsoft could devote more (paid) resources to it if there's a huge amount of work to be done. Please help? Yea, they should.

[miloush]

And they are free to devote (or not) paid resources as they see fit. A particular feature you care about might not be aligned with what they want to invest in. Still, you have the opportunity to contribute it.

Note that a consequence of large corporate is that someone allocates said resources and that someone is not necessarily the team itself, and it certainly is not the employees paid to work on WPF. Perhaps Microsoft itself does not need community contributions, but from what we have been seeing in this repo, WPF might.

While I completely agree with you that Microsoft should devote more resources to WPF, it will not happen based on a discussion in this repo. Nobody here can address your comment to your satisfaction. Talk to the management at conferences and other events, encourage business cases to be made. Make noise where it matters.

[franchyd]

And they are free to devote (or not) paid resources as they see fit. A particular feature you care about might not be aligned with what they want to invest in. Still, you have the opportunity to contribute it.

Note that a consequence of large corporate is that someone allocates said resources and that someone is not necessarily the team itself, and it certainly is not the employees paid to work on WPF. Perhaps Microsoft itself does not need community contributions, but from what we have been seeing in this repo, WPF might.

While I completely agree with you that Microsoft should devote more resources to WPF, it will not happen based on a discussion in this repo. Nobody here can address your comment to your satisfaction. Talk to the management at conferences and other events, encourage business cases to be made. Make noise where it matters.

I do think that WPF needs to make some more effort on community contributions as I see many of them languish due to no response,requests,feedback from the repo team. It is difficult to encourage community contribution as a driver of progress if noone actually looks at it (or at least there is the appearance of such)

[bricelam]

[h3xds1nz]

The only way that "they" do something in Open source project, is to contribute in the direction you want to fix. If WPF trimmability is wanted, please, please contribute to this project toward making this happens. That's really huge amount of work, so please help.

I have to disagree. A non-insignificant part of the work could have been done already but everything literally falls down on the WPF team not having enough resources/bandwidth to process the work. The lesser problem is the work itself, the integration is the real blocker (and besides the human resources, this includes having a real CI pipeline with all the tests than can be ran on-demand).

I'll give you an example. One of WPF's issues on .NET Core is the fact it still works at parts with the assumption of AppDomain's instead of ALCs, which is something that hinders a lot of plugin systems, unloadibility etc.

We've already been forced to solve this internally as it was a blocker on migration from NetFX (yes, we do self-contained deployments on a custom fork on our LoB apps) and I'd be more than happy to spend time backporting this support same as I've already done with some other stuff (not all my PRs here were backports, but some were cherry-picked). Given the current state however, I cannot justify allocating more time to spend on WPF work (even if it's just essentially backports) because being asked maybe year-or-two later (if the timeline is good) "oh why this got changed into that" requires me to spend about the same time to go back and recall why certain changes were needed, if I didn't describe these. Basically what @franchyd says.

[RektInator]

@Qianyiaz @franchyd @h3xds1nz

I just successfully used trimming on a WPF application using .NET 9. Please note: this does not trim everything. However, I ended up with a 38mb self-contained application using WPF UI + WebView2. 38mb is good enough for my use case though. Targetting windows7 instead of 10 because 10 includes some heavily bloated lib (25mb+) out of the box.

Obviously this is not a SOLUTION. It works fine for my use case. It may be good enough for others too.

My configuration:

    <PropertyGroup>
        <TargetFramework>net9.0-windows7</TargetFramework>
        <SupportedOSPlatformVersion>6.1</SupportedOSPlatformVersion>
        <UseWPF>true</UseWPF>
        <RuntimeIdentifier>win-x64</RuntimeIdentifier>
        <PublishSingleFile>true</PublishSingleFile>
        <IncludeNativeLibrariesForSelfExtract>true</IncludeNativeLibrariesForSelfExtract>
        <SelfContained>true</SelfContained>
        <EnableCompressionInSingleFile>true</EnableCompressionInSingleFile>
        <PublishTrimmed>true</PublishTrimmed>
        <IsTrimmable>false</IsTrimmable>
        <TrimMode>partial</TrimMode>
        <_SuppressWpfTrimError>true</_SuppressWpfTrimError>
        <BuiltInComInteropSupport>true</BuiltInComInteropSupport>
    </PropertyGroup>

[ali50m]

@RektInator Does it need PublishAot to be set as true?

[ivanjx]

@ali50m partial trim is not good enough for native aot thus if you enable it the app will crash at some point or not even run at all.