You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was considering moving my application from .net Framework to Net code and encountered a show stopper. One of your team member on Reddit suggested I open an issue, so here I am !
My application ( you can easily find it using my profile, i'm just avoiding advertising here) is used by many (20k+ downloads a day), and Microsoft is one of my customers.
On to my requirements :
SIngle exe (no installer)
No prerequisites or dependencies, at least for the basic startup of the app
Being able to execute off a USB stick or network folder
As small an exe as possible
Being able to run under WinPE environment is a plus
It is a desktop app using WPF right now, WPF being chosen for being not abandoned or close to be discontinued, not replaced by the new cool kid that cropped up ( MAUI ), and mature enough that I find lots of libraries doing what I need (I rely heavily on materialdesigninxaml and oxyplot ).
MAUI is too young, the numerous candidates between WPF and MAUI have been deprecated or are not being actively worked upon, or lack enough possibilities through Nugets.
Porting from .net framework to Net core 6 was easy thanks to the upgrade tool, it was done in about 30 minutes, and the app was working, great !
However, the final exe size, even when activating single exe deployment and compression, ended up around 100MB. that's more than 3 times the size of my original exe ( 30MB). This size increase comes with little to no advantages for users, so it's a tough one to sell.
I think it all boils down to trimming not being possible for WPF scenarios, to constraint the final exe size (I realize the Presentation* dll weights 30MB already, but still...).
Please enable trimming in those scenarios.
Or please give us a good workaround by letting us specify which assemblies we want to exclude from trimming, by forcing them to be included if they are among the dependencies. This will lead to us WPF developers being able to enable trimming and get it working (since we do know the dependencies and can do it manually if they're called from xaml only). Yes, it will be a tad micro-management, but getting that "force exclude from trimming" list will enable the support for all scenarios that are currently excluded.
I have little hope for this to be heard tbh, as MAUI is the cool kid on the block that will get all the attention (until it is, like many before, replaced by yet another tech - Blazor for desktop anyone ?).
Just don't let old, reliable, common technologies fade away in your support in net6. Even if they don't have all the bells and whistles of newer techs, lots of apps are heavily relying on it.
The text was updated successfully, but these errors were encountered:
I was considering moving my application from .net Framework to Net code and encountered a show stopper. One of your team member on Reddit suggested I open an issue, so here I am !
My application ( you can easily find it using my profile, i'm just avoiding advertising here) is used by many (20k+ downloads a day), and Microsoft is one of my customers.
On to my requirements :
It is a desktop app using WPF right now, WPF being chosen for being not abandoned or close to be discontinued, not replaced by the new cool kid that cropped up ( MAUI ), and mature enough that I find lots of libraries doing what I need (I rely heavily on materialdesigninxaml and oxyplot ).
MAUI is too young, the numerous candidates between WPF and MAUI have been deprecated or are not being actively worked upon, or lack enough possibilities through Nugets.
Porting from .net framework to Net core 6 was easy thanks to the upgrade tool, it was done in about 30 minutes, and the app was working, great !
However, the final exe size, even when activating single exe deployment and compression, ended up around 100MB. that's more than 3 times the size of my original exe ( 30MB). This size increase comes with little to no advantages for users, so it's a tough one to sell.
I used this build command :
I think it all boils down to trimming not being possible for WPF scenarios, to constraint the final exe size (I realize the Presentation* dll weights 30MB already, but still...).
Please enable trimming in those scenarios.
Or please give us a good workaround by letting us specify which assemblies we want to exclude from trimming, by forcing them to be included if they are among the dependencies. This will lead to us WPF developers being able to enable trimming and get it working (since we do know the dependencies and can do it manually if they're called from xaml only). Yes, it will be a tad micro-management, but getting that "force exclude from trimming" list will enable the support for all scenarios that are currently excluded.
I have little hope for this to be heard tbh, as MAUI is the cool kid on the block that will get all the attention (until it is, like many before, replaced by yet another tech - Blazor for desktop anyone ?).
Just don't let old, reliable, common technologies fade away in your support in net6. Even if they don't have all the bells and whistles of newer techs, lots of apps are heavily relying on it.
The text was updated successfully, but these errors were encountered: