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

• Generate list of warnings produced when linking a representative WPF app
• Categorize warnings, sorting to netcore warnings and WPF-specific warnings (see Developers want to be confident that their apps run successfully when trimmed to avoid debugging trimming related problems at runtime runtime#43078)
• 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.