4 ms·

.NET can create self-contained executables pretty easily (via _dotnet publish_), both including the required framework assemblies and without them. But they'll

.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.

neonsunset 1y ago
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.
- maneki-neko 1y ago
  > 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.
  - neonsunset 1y ago
    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).
    - notpushkin 1y ago
      GP argues that UI frameworks in .NET come and go, despite each one being “the final one”.
  - int_19h 1y ago
    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.
- pjmlp 1y ago
  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/microsoft-ui-xaml/issues https://github.com/microsoft/WindowsAppSDK/issues https://github.com/microsoft/WindowsAppSDK/issues https://github.com/microsoft/CsWinRT/issues https://github.com/microsoft/CsWinRT/issues https://github.com/microsoft/cppwinrt/commits/master/ https://github.com/microsoft/cppwinrt/commits/master/
  - neonsunset 1y ago
    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 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.
    - pjmlp 1y ago
      Fair enough, although I trust them more to sort out those issues, than to keep waiting for Project Reunion to deliver what was promised at BUILD 2020, or by C++/WinRT team at CppCon 2017 (which is WinUI 3.0 foundation).
TiredOfLife 1y ago
Are those not just large zip files?
- Xss3 1y ago
  Does it matter what format they use to pack the exe with data?
- pjmlp 1y ago
  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.
scotty79 1y ago
I couldn't find the right checkbox to click in VS.

.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.

neonsunset 1y ago

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.

maneki-neko 1y ago
> 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.
- neonsunset 1y ago
  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).
  - notpushkin 1y ago
    GP argues that UI frameworks in .NET come and go, despite each one being “the final one”.
- int_19h 1y ago
  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.
pjmlp 1y ago
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/microsoft-ui-xaml/issues https://github.com/microsoft/WindowsAppSDK/issues https://github.com/microsoft/WindowsAppSDK/issues https://github.com/microsoft/CsWinRT/issues https://github.com/microsoft/CsWinRT/issues https://github.com/microsoft/cppwinrt/commits/master/ https://github.com/microsoft/cppwinrt/commits/master/
- neonsunset 1y ago
  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 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.
  - pjmlp 1y ago
    Fair enough, although I trust them more to sort out those issues, than to keep waiting for Project Reunion to deliver what was promised at BUILD 2020, or by C++/WinRT team at CppCon 2017 (which is WinUI 3.0 foundation).

TiredOfLife 1y ago

Are those not just large zip files?

Xss3 1y ago
Does it matter what format they use to pack the exe with data?
pjmlp 1y ago
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.

scotty79 1y ago

I couldn't find the right checkbox to click in VS.