WPF is not trim-compatible #3811
Comments
|
Here is the list of all the linker warnings that I get when publishing a wpf app with |
ryalanms
added
the
Enhancement Requested
|
WPF specific warnings can be seen in the file below, 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
|
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? |
|
It seems very unlikely this will be done for 6.0. I'll leave it up to @ryalanms to comment on WPF resourcing/scheduling. |
|
Is there an update on this? Might it make it into .Net 7.0 ? |
|
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. |
|
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. |
|
@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: |
|
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. |
|
@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. |
|
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. |
|
@kant2002 any updates on this? |
|
@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, Other option probably would be sponsor some for of WPF, that probably would be faster 😉 |
|
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 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 |
|
How about https://github.com/yangzhongke/Zack.DotNetTrimmer ? Zack.DotNetTrimmer supports Windows Forms and WPF. |
Yeah for smaller projects it's probably okay, but not everyone has that much time on every publish:
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. |
This is minimal change which replace usage built-in COM for IThThreadMgr instance. Having ComWrappers is important to make dotnet#3811 works.
And use v4.6.2 to maximize portability as it's the earliest supported version (https://docs.microsoft.com/en-US/lifecycle/faq/dotnet-framework). The only features we were missing are the init setters in Monitor.cs, but that's an easy change. File size is under 400KB. On self-contained .NET Core it's over 150MB! Without trimming (dotnet/wpf#3811) on self-contained deployment, it's very hard to justify the file size, and not being self-contained isn't an option as Windows doesn't come with a system install of .NET Core.
This is minimal change which replace usage built-in COM for IThThreadMgr instance. Having ComWrappers is important to make dotnet#3811 works.
|
Hello, is there any update on this ? |
|
godot 4 c# is closer to this vision than ever before => #3811 (comment) |
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
Goals
Progress
Information gathering
Code fixes
The text was updated successfully, but these errors were encountered: