-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ReadyToRun + WPF + PublishTrimmed=true does not generate valid executable #60936
Comments
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov Issue DetailsDescription
Edit: Find line Run command:
go into folder Produced build weights around 64 Mb, which is maybe 25% of original executable (with When trying to launch in debugger - it will produce following error:
contains a lot of configurations of different trimming options - you can either comment What I by myself find to be rather difficult - is configuring trimming with right options Based on debugging experience it's rather difficult or even impossible to say If you reconfigure using different trimming options - you will get other errors after that. Another example - if you modify csproj, and remove all other
after that application fails to start with following exception:
This exception I was not able to solve no matter what. Suspect need to use
|
Hey @tapika, The problem is that your EnsureAllAssembliesAreLinked target does not do anything at the moment. The multiple ManagedAssemblyToLink sets TrimMode to copyused, which is already the default. The multiple TrimmerRootAssembly must be outside of the target to be used. You can either replace copyused for false or move your TrimmerRootAssembly outside of your target. I was able to remove the target EnsureAllAssembliesAreLinked completely in favor of this code:
Hope this helps! |
Ok, that was impressive - 160 Mb is already something. App even starts and seems to work more or less right. On exit however there is an exception:
But I can try out later on to add more TrimmerRootAssemblies. But I want to squeeze that 160 Mb further. For choco |
Hey @tapika, I'm glad you've had luck with .NET 5, but unfortunately WPF is not trim-compatible for .NET 6. As you've seen, as the trimmer gets more intelligent, it starts to trim away things that WPF needs to keep running. WPF hasn't had any modifications to deal with trimming, so it can't communicate what's necessary to the trimmer. More info on incompatibilities at https://docs.microsoft.com/en-us/dotnet/core/deploying/trimming/incompatibilities. For a tracking issue on the trimming problems in WPF, see dotnet/wpf#3811 |
Ok, now managed to study ReadyToRun bit deeper. Unlike you suggested - Chocolatey GUI is based on netcoreapp3.1 platform, not net5.0 / net6.0. And adding couple of assemblies to trim - also exit exception went away.
For some reason I did not need to add other assemblies - suspect because I've fixed couple app internal bugs (which came because of .net core update) and will continue Now install / uninstall seems to be working more or less. (At least tested on putty package) Resulting file size 168 Mb ( I think 168 Mb is still bit too big package size, and I started to wonder whether I I've managed to compress executable into 58 Mb, and app was still working. One disadvantage I saw in whole story is that directory is hardcoded But if you cross compare with ReadyToRun - with ReadyToRun folder is also hardcoded And that directory is also not cleaned (like in wrap case Wondering whether it's possible to provide extraction path folder to ReadyToRun and also control cleanup logic. (I can raise new issues as necessary) Then finally I've find out that .net 6.0 should support compression out of box - it's mentioned in here: See I've got interested and attempted to upgrade Chocolatey GUI to .net 5 & 6 - I've partially managed to do that one
To build on .net 5.0 platform:
It does build .exe (which is 157Mb) - Same problem persists also in .net 6.0 platform - so maybe I need to create new bug-issue for this one. Interesting thing that build works - as I have configured UI to use ProjectsCommon.props /
gives error:
Why ? On netcore3.1 & net5.0 this seems to be working ?
Seems to go further, but also fails, I guess this was the problem you've mentioned about disabling WPF trimming.
By uncommenting lines:
build seems to go through (with native dll present problem mentioned above) With .exe produced size is 94 Mb. It's compressed , but is it possible to adjust compression level or using different compression algorithm ? Using 7-zip from here: https://github.com/mcmilk/7-Zip-zstd/releases + brotli compression for example it's possible to squeeze .exe to 36 - 41 Mb, which gives better compression ratio than .net 6.0. Is self extracting executable of ReadyToRun a public source code ? |
Note that on .NET 6 publishing as single-file will not extract any managed assemblies. Only native libraries which are explicitly added to the bundle (
Because on .NET 6 the runtime is part of the executable (statically linked) and not extracted. On Win7 the runtime needs the
Currently no. For simplicity we used the deflate algorithm available in CoreCLR runtime already. We also prioritized decompression speed over everything else for now.
Yes - the design docs for the feature are here. |
What if I would like that path to be configurable by the one who creates that bundle ? Only thing which worries me - is that amount of files can change from one build to another, and it's not safe to keep previous versions of older bundle. I would prefer that all directories would remain in control of application, but all .dll files which exists on target path would be preserved only if they are part of bundle. Not clearing is ok from my perspective.
I would prefer to have compression present, even configured to maximum + decompression handled to file system still. If I create any new issue - to which .net versions it can be implemented - only to .net 6 or also older (.net 5 / .net 3.1 ?)
I could recommend to check sheet from here: https://quixdb.github.io/squash-benchmark/#results And github itself: https://github.com/quixdb/squash Using API similar to or even exactly squash plugins can hide you compression behind one clean cut api. If I'll raise issue to support other compression codecs (I would propose to start from brotli) - would that be accepted for implementation ? |
#35249 - this is basically the same discussion. Overall I think this is getting into the gray area of:
Currently our goals are in the former bucket. The single-file feature is not meant to replace installers and similar technologies.
Most likely answer is .NET 7+. We typically don't ship new functionality in servicing releases (too much risk associated), unless there's a really good reason to do so.
As with any other feature this depends on many trade offs:
|
As installer you probably mean packaging technology, which purpose is to bring application for first time on computer ? First time is good, but if you think about it - application may need also second, third, and so on times to bring itself to computer - like software update. If installer technology does not satisfy developer needs, then custom install+software update technologies will be born to replace installer technologies. :-) Anyway, I think I've managed to have now readytorun with size 60 Mb (choco) - that is cli only, and 168Mb with UI (choco gui). if 168Mb weights too much, I can use 60Mb to bring .net core or .net framework install and continue from there. I think end-user will survive that for first installation he will have no UI, but after that UI will be present. And even that 168 Mb is not that bad if whole application installation is measured in Gb:s. |
I think this ticket can be closed. Parameter handling is not perfect, but at least it works. |
Description
git clone https://github.com/tapika/swupd.git
Edit:
build.ps1
Find line
"$publishTrimmed = 'false'"
- comment it out using '#' (Without trimming executable works correctly)Run command:
build.bat buildexe_chocogui_win7
go into folder
src\ChocolateyGui\bin\publish_win7-x64
Produced build weights around 64 Mb, which is maybe 25% of original executable (with
PublishTrimmed=true
)When trying to launch in debugger - it will produce following error:
src\ChocolateyGui\ChocolateyGui.csproj
contains a lot of configurations of different trimming options - you can either comment
them out or fix them as they should work.
What I by myself find to be rather difficult - is configuring trimming with right options
for right libraries.
Based on debugging experience it's rather difficult or even impossible to say
which error results because of which missing dll / class / etc...
If you reconfigure using different trimming options - you will get other errors after that.
Another example - if you modify csproj, and remove all other
ManagedAssemblyToLink
xml tags and leave only lines:after that application fails to start with following exception:
This exception I was not able to solve no matter what. Suspect need to use
<TrimMode>copyused</TrimMode>
for some of dlls, but which ?!The text was updated successfully, but these errors were encountered: