2 ms·
What kind of build settings lead to 500 MiB binaries? I struggle to imagine something that could make the toolchain to emit such a large binary save for select
by neonsunset 2y ago
What kind of build settings lead to 500 MiB binaries? I struggle to imagine something that could make the toolchain to emit such a large binary save for select degenerate cases of runaway generic specialization when you AOT compile an SDK that combines LINQ with 2102718201 enum types, all of which get their own set of generic instantiations for every internal iterator within LINQ - that's a known issue that is fixed by enabling identical method folding in ILC, the worst offender used to be Kiota OpenAPI generator causing this, but thanks to tireless work by Filip Navara that was fixed there.
In general, there are quite a few knobs for configuring how exactly you would like to have your application published. This is also an area of active improvement with each new release as you noted. It is very worth it to look into further build configuration nonetheless. If you still face an issue with "this surely shouldn't take this much space", it might be a good idea to submit it to either https://github.com/dotnet/runtime https://github.com/dotnet/runtime or to the repo of the GUI framework depending on where you think the fault lies - without feedback it's difficult to know if there is an area that needs improvement or a known improvement opportunity that has demand.
- smileybarry 2y agoIt’s just because the WinUI3 libraries and/or .NET Core runtime take that much. Mostly WinUI3 IIRC. And that’s when you use “selfcontained mode” rather than AOT publishing, now with AOT it’s considerably better.
- neonsunset 2y agoSelf-contained/single-file mode is compatible with trimming and benefits from the work done to improve AOT story. As AOT binaries get smaller and ILLink's analysis gets smarter, the single-file trimmed binaries will see a part of such improvements. The issue is that many GUI frameworks are not AOT-incompatible per se but rather trim-incompatible as they rely on reflection that is done in a way that is totally opaque to ILLink save for rooting everything. You can try the following publish option anyway, and in many instances it "just works" (assuming .NET 8 SDK): dotnet publish -o out -p:PublishSingleFile=true -p:PublishTrimmed=true Note: trimming was introduced in .NET 6, and NativeAOT was initially introduced in 7, so it had seen quite a bit of work to mature and improve by the time 8 shipped.
- pjmlp 2y agoIf only UWP had a AOT compilation story for .NET code that could be re-used for WinUI 3.0.... And then there is the whole C# / C++ interop between CsWinRT and C++/WinRT.
- pjc50 2y agoWinUI3 itself. If you want to be "normal", or at least follow the Microsoft semi blessed path, and make an appx, that does not include WinUI3. The user installs it, and in the process pulls down WinUI3 (also an appx) if it is not already installed. It's only if you really insist on "self-contained" that this problem arises. I say semi-blessed because of course Microsoft aren't really committed to WinUI3 and barely any of their own apps use it.
- pjmlp 2y agoYou should browse the set of WinUI related repos, YouTube community calls and Developer Connection, feedback is something they aren't short of.