4 ms·

> While it’s a bit cumbersome, he doesn’t really point out any major flaw with the WinForms/WPF ideas, other than of course requiring two stacks. He says he wan

> While it’s a bit cumbersome, he doesn’t really point out any major flaw with the WinForms/WPF ideas, other than of course requiring two stacks. He says he wants native code and wouldn’t want any C# visible but doesn’t explain why. Fear of reverse engineering? UI code rarely contains anything secret. What I find the most mind-numbing thing about the blog post is the way WinUI3 was excluded. WinUI3 looks like an exact match for the blogger's most critical requirements, specially the customization thing, and there is absolutely no better way to target Windows than Microsoft's official GUI offering, but somehow that one is rejected? Absurd.

mike_hearn 2y ago
Some of the issue is he has outdated understanding of AppX packages (MSIX). You can use all of Win32 from an MSIX package, and all of WinRT, and WinUI3 etc. It's actually the other way around: there are some Win32 APIs that only work if your app is packaged.
pjmlp 2y ago
Anyone that has used WinUI since its inception, knows that the best for our sanity is to avoid it at all costs. It is still years away to provide feature parity with UWP/WinUI 2.0, let alone the Windows Forms, WPF capabilites and Visual Studio tooling. Using it from C++ is only for ATL / VisuaL C++ 6.0 die hards.
smileybarry 2y ago
WinUI3 is a can of worms that’s becoming palatable only with .NET 8 (and soon 9). In a normal configuration, you have to bring 500MB of dependencies with you, or ask the user to install a redistributable. You also need the user to install .NET 8, or bring said 0.5GB with you. WinUI3 can be used in unpackaged apps (I.e.: not appx) but has a few random caveats that just don’t work; random APIs that have a footnote of “oh this doesn’t work in unpackaged apps” or “works in unpackaged apps but only in .NET Preview something-something”. .NET 8 fixes a lot of this by adding AOT compilation and single-binary releases, but it’s still fairly large. .NET 9 then improves culling of unused framework code from your published file, and also adds WPF -> WinUI3 theming support. Source: my repeated attempts to rewrite our product’s UI in WinUI3 (from WPF on .NET Framework 3.5) several times.
- 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 ago
    It’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 ago
      Self-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.

mike_hearn 2y ago

Some of the issue is he has outdated understanding of AppX packages (MSIX). You can use all of Win32 from an MSIX package, and all of WinRT, and WinUI3 etc. It's actually the other way around: there are some Win32 APIs that only work if your app is packaged.

pjmlp 2y ago

Anyone that has used WinUI since its inception, knows that the best for our sanity is to avoid it at all costs. It is still years away to provide feature parity with UWP/WinUI 2.0, let alone the Windows Forms, WPF capabilites and Visual Studio tooling. Using it from C++ is only for ATL / VisuaL C++ 6.0 die hards.

smileybarry 2y ago

WinUI3 is a can of worms that’s becoming palatable only with .NET 8 (and soon 9). In a normal configuration, you have to bring 500MB of dependencies with you, or ask the user to install a redistributable. You also need the user to install .NET 8, or bring said 0.5GB with you. WinUI3 can be used in unpackaged apps (I.e.: not appx) but has a few random caveats that just don’t work; random APIs that have a footnote of “oh this doesn’t work in unpackaged apps” or “works in unpackaged apps but only in .NET Preview something-something”. .NET 8 fixes a lot of this by adding AOT compilation and single-binary releases, but it’s still fairly large. .NET 9 then improves culling of unused framework code from your published file, and also adds WPF -> WinUI3 theming support. Source: my repeated attempts to rewrite our product’s UI in WinUI3 (from WPF on .NET Framework 3.5) several times.

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 ago
  It’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 ago
    Self-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.