361–370 of 577 posts
Earlier quoted context omitted.
.NET since 6 (I think) can be published as a self contained app with the runtime included. It immediately adds some size to the output but you can mitigate it with AOT and trimming.
AOT is currently only available in CLI apps. It's expected for WinUI 3 apps using WASDK v1.6 closer to the end of the year.
Is 40MB a lot nowadays? Eg the argocd cli is 155MB, and that's just a relatively simple cli app that as far as I know just calls a remote api.
Welcome to bloatworld I guess.
Earlier quoted context omitted.
Which particular .NET Gui? There is a collection of them: MAUI, WPF, Blazor Hybrid, WinUI. Microsoft have utterly screwed the pooch on getting their .NET GUI story straight.
WinUI 3 is the default for Windows-only applications
No one burned with WinRT history since Windows 8, is ever touching WinUI, unless they are Microsoft employees on WinDev, or companies with sunken costs trying to keep their products around.
Earlier quoted context omitted.
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 “…
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…
Earlier quoted context omitted.
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.
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…
And then there is the whole C# / C++ interop between CsWinRT and C++/WinRT.
Earlier quoted context omitted.
Agreed. I had the exact same question. From the article: "The issue is that with bundling the .dll, it would still mean it being extracted somewhere and writing additional code for the P/Invoke to work, and C++/CLI gets compiled to .NET IL code, in other words, you can open the resulting app in dnSpy and see the C++ code translated to C# equivalent (which is not what I want, I want native code)." I don't understand w…
C++/CLI is managed code, it’s basically C++ compiled into .NET IL. If you’re writing C++ code running on .NET / .NET Framework, you’re basically writing masochistic C#.
Also C++/CLI can also generate native code when specific code patters are used, that is why there are some compiler flags to disable it, and such assemblies are considered unsafe.
Earlier quoted context omitted.
WPF has been superseded (supposedly) by UWP / WinGUI / MAUI / Blazor?
UWP was designed primarily for Windows phones, usability on desktops suffers. And it requires windows store, you can’t just ship an installer .exe WinUI seems to be copy-pasted from UWP, same usability issues on desktops. Unlike UWP, it’s a mess in terms of software quality. Also the runtime is huge, I think the size in MB even exceeds Electron. About MAUI, it seems Microsoft decided to make an abstraction over nativ…
Miguel de Icaza is pretty sour on this, and quite likely one of the reasons he is now fully into Apple ecosystem and Swift.
Blazor started with being only a WebAssembly based framework, then they decided to put everthing on ASP.NET under Blazor umbrella, and are now pushing Blazor into everything that has a Webview, including the stupid idea of Hybrid Blazor in MAUI, basically Electron in .NET.
Earlier quoted context omitted.
.NET since 6 (I think) can be published as a self contained app with the runtime included. It immediately adds some size to the output but you can mitigate it with AOT and trimming.
AOT is currently only available in CLI apps. It's expected for WinUI 3 apps using WASDK v1.6 closer to the end of the year.
And naturally single-file + trimmed works almost everywhere, in some situations requiring to add attribute annotations for un-analyzable reflection usage patterns.
I'm teaching myself the Win32 API for a future RE project, thinking that knowing it helps with the reverse engineering effort. I have just achieved creating a window, loading a text file and printing it on the main window. Scrollbars are there but don't work yet. It actually take s a lot of work. The boilerplate code is OK but I never realized that showing strings on Windows is such a PIA. I have deep respect for any…