3 ms·

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, o

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.
    - pjmlp 2y ago
      If 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 ago
  WinUI3 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 ago
  You should browse the set of WinUI related repos, YouTube community calls and Developer Connection, feedback is something they aren't short of.
whywhywhywhy 2y ago
I don't understand why Microsoft puts it on the user/dev to make sure their own dependencies and "VC redistributables" are installed. Like shouldn't Windows 11 just either have that already or pull it down as needed as it's an official MS library. Feel I always hit a roadblock when setting up a new PC where one of the things needs that but the dev didn't provide it and I have to get it myself. Which feels weird when it's an official MS thing from their official dev tools.
- HumblyTossed 2y ago
  > Like shouldn't Windows 11 just either have that already or pull it down as needed as it's an official MS library. In this day and age of everything always connected, some things still aren't always connected.
  - estebank 2y ago
    The app manifest could state "I need this runtime installed". The OS can know whether it is already installed or not. The OS also knows whether it is internet connected or not. If a runtime that isn't installed is needed and internet connectivity isn't available, the OS could state that, with information about how to procure the runtime manually. That would stop people that have copied thr application from a pendrive in an air gapped system, that's true. One could make the case that someone meeting all of those requirements for would be technically minded enough to figure it out. This wouldn't help developers who want to distribute a small application that won't ever require a download, but would be an improvement for anyone already distributing .Net applications over the web.
    - whywhywhywhy 2y ago
      The OS presumably also knows where I should get it from as the same company hosts the installer as ships the OS. Yet IIRC the error is just an obtuse thing complaining a DLL isn't there and through googling and hopefully finding your way to Microsoft.com not some malware site you have to find the installer yourself. Mild annoyance for someone with 28 years Windows experience, complete roadblock or malware vector for someone who just wants to use a computer rather than understand a computer.

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.
  - pjmlp 2y ago
    If 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 ago
WinUI3 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 ago
You should browse the set of WinUI related repos, YouTube community calls and Developer Connection, feedback is something they aren't short of.

whywhywhywhy 2y ago

I don't understand why Microsoft puts it on the user/dev to make sure their own dependencies and "VC redistributables" are installed. Like shouldn't Windows 11 just either have that already or pull it down as needed as it's an official MS library. Feel I always hit a roadblock when setting up a new PC where one of the things needs that but the dev didn't provide it and I have to get it myself. Which feels weird when it's an official MS thing from their official dev tools.

HumblyTossed 2y ago
> Like shouldn't Windows 11 just either have that already or pull it down as needed as it's an official MS library. In this day and age of everything always connected, some things still aren't always connected.
- estebank 2y ago
  The app manifest could state "I need this runtime installed". The OS can know whether it is already installed or not. The OS also knows whether it is internet connected or not. If a runtime that isn't installed is needed and internet connectivity isn't available, the OS could state that, with information about how to procure the runtime manually. That would stop people that have copied thr application from a pendrive in an air gapped system, that's true. One could make the case that someone meeting all of those requirements for would be technically minded enough to figure it out. This wouldn't help developers who want to distribute a small application that won't ever require a download, but would be an improvement for anyone already distributing .Net applications over the web.
  - whywhywhywhy 2y ago
    The OS presumably also knows where I should get it from as the same company hosts the installer as ships the OS. Yet IIRC the error is just an obtuse thing complaining a DLL isn't there and through googling and hopefully finding your way to Microsoft.com not some malware site you have to find the installer yourself. Mild annoyance for someone with 28 years Windows experience, complete roadblock or malware vector for someone who just wants to use a computer rather than understand a computer.