Comment by nanoxide
1 month ago
.NET can create self-contained executables pretty easily (via _dotnet publish_), both including the required framework assemblies and without them. But they'll still be comparatively large.
1 month ago
.NET can create self-contained executables pretty easily (via _dotnet publish_), both including the required framework assemblies and without them. But they'll still be comparatively large.
I couldn't find the right checkbox to click in VS.
Are those not just large zip files?
Not necessarly, that is a possible option if you want to keep the JIT around, other one is to AOT compile, 100% straight machine code, like any other compiled language.
Does it matter what format they use to pack the exe with data?
For JIT binaries it’s best to apply /p:PublishTrimmed=true which (sometimes massively) reduces their size. Applications written in AvaloniaUI or, nowadays, WinUI 3 can be compiled with NativeAOT which reduces the size and memory usage even further.
> written in AvaloniaUI or, nowadays, WinUI 3
Be aware that this is what you're getting into when you pick dotnet for GUI applications. It's been that way for decades at this point, there are many unfixed bugs in WPF for example, in spite of it being touted as the final word in GUI development in its time and still being used for some Microsoft applications like VS.
Meanwhile, with Delphi you were using VCL 20 years ago, and you're still using VCL today, and its development velocity and performance is light years ahead of anything Microsoft put out during that time. This also applies to Lazarus's LCL.
Even so I would still pick WPF over VCL/LCL today if I don't need cross-platform support. It just does so much more, especially when it comes to data binding.
The funny thing about Windows GUI story is that the older the framework is, generally speaking, the better it is supported. WinForms still gets bug fixes and improvements; so does WPF. OTOH if you were early on the WinRT bandwagon, tough luck, and it's been meaningless churn ever since.
Wait what? AvaloniaUI is not WPF, neither is WinUI3 which is new and maybe something you'd consider if you only target Windows (I presume it's better than using it through Uno, otherwise you'd probably choose Avalonia to support all OSes).
1 reply →
100% great advice, but really better go with Avalonia, Uno, WPF, Windows Forms, WinUI 3.0 only if one is a Microsoft employee.
https://github.com/microsoft/microsoft-ui-xaml/issues
https://github.com/microsoft/WindowsAppSDK/issues
https://github.com/microsoft/CsWinRT/issues
https://github.com/microsoft/cppwinrt/commits/master/
I was going to complain how Avalonia still has issues with large binaries even with NAOT but I just tested it on https://github.com/sourcegit-scm/sourcegit on Windows, and the resulting size of the folder without symbols (the binary and like 4 dlls) is ~55MiB. The binary itself is 41MiB which is as much as Qt6-based qBitorrent binary takes on Windows. So it seems while Avalonia works well enough on macOS, the size of binaries and memory consumption are higher than on Linux and Windows huh.
1 reply →