site banner
PaperclipPerfector  1mo ago (text post)   2354 thread views

Friday Fun Thread for October 11, 2024

Be advised: this thread is not for serious in-depth discussion of weighty topics (we have a link for that), this thread is not for anything Culture War related. This thread is for Fun. You got jokes? Share 'em. You got silly questions? Ask 'em.

1
Top Bottom Old Controversial Comments
Jump in the discussion.

No email address required.

Yeah 160mb is insane, I've seen very few apps that large. Front-end frameworks can be nasty.

The default settings for almost any .NET Core gui (WinForm or WPF) app will give you ~120mb+ files, and a mess of them. Bundling almost the whole runtime into each deployment is supposed to avoid the pain of a separate runtime installation, but it's a messy tradeoff either way.

There's an 'app trimming' config that tries to reduce bloat a bit. It's kinda annoying and doesn't do a great job even in the best-case scenarios, though.. Unfortunately, one of the better arguments for sticking with .NET Framework, especially if considering mass deployment -- if you can get away with .NET Framework 4.x- or earlier features, Win10 and Win11 have it included by default and still leave (admittedly bulkier-than-necessary) <10MB executable.

If you're just deploying to Windows machines, it's genuinely not hard to use newer .NET versions to produce that <10MB GUI binaries most of the time:

  • If you know your deployment runtime (for .NET Desktop, win-x86, win-x64, or win-arm64), in modern versions of .NET you can just dotnet publish -r <runtime> and it skips the default runtime bloat. Of course, you now have to deploy the right binary to your user, but this isn't hard in 2024 - Windows on ARM is basically a fantasy, W11 doesn't even have an x86 version any more, and W10 is going out of support next year (whether you like it or not - RIP).
  • You don't have to bundle the runtime with your application. For the minor annoyance of adding some extra code to your installer bundle to download and execute the runtime installer when the runtime is absent, you can convincingly gaslight your users into thinking your application is just the tiny binary, and the runtime library is just some weird Windows thing that came along for the ride. And this is basically what you had to do with Visual C++ Runtimes, so it's not like the users haven't been doing this for years...

I guess if you're optimizing for binary size, you're never gonna beat Microsoft bundling the .NET Framework binaries directly into every Windows distribution for you. But if you can, come join us in the future! I uplifted a .NET Framework 4.5 application to .NET 8.0 Desktop with about 10 lines of inconsequential code changes and some project file hackery, then attached new pieces to the project using abstract static interfaces and generic math only available in .NET 7 or greater, and added a few lines of code to a bundled installer to download the runtime from Microsoft. It all just works, it's about 20% faster on the critical path, my binary size went from 1MB to about 1.5MB, and it took me a day instead of a month to add the new feature I needed. It's great.

I won't claim there's no reason to use .NET Framework any more (particularly if you committed crimes against humanity with AppDomains), but the happy path for most new GUI development in C# targeting Windows should point you squarely at .NET Desktop on the most modern version of .NET LTS (the even-numbered ones). It's infinitely more tolerable than the other garbage desktop front-end frameworks excreted and subsequently rug-pulled a year or two later by Microsoft in the last few years (UWP, MAUI, WinUI x where {x ∈ N, x < ∞}), it's not a website and some WASM in a trenchcoat (Blazor, ElectronNET), and you still get all the WPF goodness (and WinForms, if you really want it).

Ah, I stand corrected then. Last time I tried was early in the .NET Core 5 days, and turning off everything but x86_64 and using aggressive trimming still left >30MB deployments for some of the common projects I was working with at the time. They were admittedly weird in ways I can see the linker panicking about, but they weren't that weird. Will have to try it out again.

It all just works, it's about 20% faster on the critical path, my binary size went from 1MB to about 1.5MB, and it took me a day instead of a month to add the new feature I needed. It's great.

Yeah, if you're doing anything even moderately performance-, security-, or complexity-dependent, Desktop or Core make a lot more sense. It's mostly light apps like the 'write data from interface to text file' or your standard CRUD that a lot of the bennies just aren't going to come up.

((And I'll admit I've abused the fuck out of AppDomain.UnhandledException, given how hard it is to get error reports with actual details from Microsoft.))

It's infinitely more tolerable than the other garbage desktop front-end frameworks excreted and subsequently rug-pulled a year or two later by Microsoft in the last few years (UWP, MAUI, WinUI x where {x ∈ N, x < ∞}), it's not a website and some WASM in a trenchcoat (Blazor, ElectronNET), and you still get all the WPF goodness (and WinForms, if you really want it).

Definitely agreed there. For simple GUI applications, the .NET ecosystem as a whole is just incredibly convenient. Even looking at competitors outside of Microsoft, it's vastly more convenient than trying to fight with JavaFX or Swing for almost every case excepting where absolutely need (reliable) Linux support (and I'd be tempted to say fuck it and try mono even there), it's a lot more robust that using JS and pretending your web browser is a reliable application, and the less said about QT the better.

What is this place?

This website is a place for people who want to move past shady thinking and test their ideas in a court of people who don't all share the same biases. Our goal is to optimize for light, not heat; this is a group effort, and all commentators are asked to do their part.

The weekly Culture War threads host the most controversial topics and are the most visible aspect of The Motte. However, many other topics are appropriate here. We encourage people to post anything related to science, politics, or philosophy; if in doubt, post!

Check out The Vault for an archive of old quality posts. You are encouraged to crosspost these elsewhere.


Why are you called The Motte?

A motte is a stone keep on a raised earthwork common in early medieval fortifications. More pertinently, it's an element in a rhetorical move called a "Motte-and-Bailey", originally identified by philosopher Nicholas Shackel. It describes the tendency in discourse for people to move from a controversial but high value claim to a defensible but less exciting one upon any resistance to the former. He likens this to the medieval fortification, where a desirable land (the bailey) is abandoned when in danger for the more easily defended motte. In Shackel's words, "The Motte represents the defensible but undesired propositions to which one retreats when hard pressed."

On The Motte, always attempt to remain inside your defensible territory, even if you are not being pressed.


New post guidelines

If you're posting something that isn't related to the culture war, we encourage you to post a thread for it. A submission statement is highly appreciated, but isn't necessary for text posts or links to largely-text posts such as blogs or news articles; if we're unsure of the value of your post, we might remove it until you add a submission statement. A submission statement is required for non-text sources (videos, podcasts, images).

Culture war posts go in the culture war thread; all links must either include a submission statement or significant commentary. Bare links without those will be removed.

If in doubt, please post it!


Rules


Recommended Posts And Communities

Recommended Realtime Chats