Even small utilities in dot net core are ridiculously big and have tens of dll files. Maybe a proper dependency management is needed so that only what parts of the framework that are actually used are included in the executable.
This "publishTrimmed=true" is demo'd in this video https://channel9.msdn.com/Events/Build/2020/BOD106
Starting around 00:46:30
https://github.com/AustinWise/IlLinkerExample
You basically have to directly fiddle with the flags to the IL linker to really get the size down. It's a pain. They are working on designs to make it better:
https://github.com/dotnet/designs/pull/123
I think these changes can make self contained .NET apps compare more favorably to Go apps, at least for larger applications. It would probably take something more like CoreRT to get app size to be competitive with Rust and C.
(sobs woefully)
That's 3 orders of magnitude difference. Obviously it won't be as much with more complex applications, but it's still funny to see others here considering a dozen MB or so for doing something trivial to be small, when that's the size of a full installation of Windows 3.11 complete with all its built-in apps.
You'll have several GUI apps installed on user system...
UWP already handled that years ago, thought.
.msix/.appx supports dependency properly. If the app target's a new .NET version, and it doesn't have downloaded, it just.... download automatically on install. UWP .NET on Windows it's also inside .appx packages.
> We're talking about saving how much disk space anyway?
Surely this is relevant to how the customer values disk space, not the developer.
Tons. Serialization, for one, And plugin systems are commonplace.
> You have zero grounds to dictate the value of resources.
Nonsense and worse words. We know how much disk costs. It is a rounding error for the overwhelming majority of people and the overwhelming majority of apps. Prioritize what matters.
Surely this is doable statically. What is the advantage of doing this at runtime rather than at compile time?
> Nonsense and worse words. We know how much disk costs. It is a rounding error for the overwhelming majority of people and the overwhelming majority of apps. Prioritize what matters.
Got a citation? Disk space is the only variable that people even know to complain about... Not sure what you're drawing this from but it stinks to high heaven of corporate propaganda.
If you're talking about the server side....well I think you'd save a lot more on less vCPU than a little more attached storage.
So let me put it back on you: except maybe IoT, where do you run into problems where your app takes up too much disk space?
EDIT: Maybe it's an update/bandwidth thing? Or a Docker pull time in CI? I'm trying to play devil's advocate here...
What does this have to do with C#? Surely you hold it to a higher standard than electron of all things—C# has been around for 18 years. Electron is just repackaging a browser as an app. Is this the standard to which microsoft holds themselves? Might as well sell scripts for google docs....
I'm not sure where "Disk space is the only variable that people even know to complain about" did come from, but games use 100-150 GBs nowadays, so things like 17 MB are basically irrelevant unless you do verrrrrrrrry specific stuff
If you have a phone with 8G of space like I do, obviously games which require 150G are beyond my means. How does this work towards disk space being irrelevant?
We know how much disk costs, but at any given moment a certain non-negligible share of businesses will be working with very old equipment in some of their branch offices, self-service terminals, factory floors, labs, etc.
I agree that 17 MB will rarely be a show stopper in isolation. But resource consumption is critical if Microsoft wants .NET to be a universal solution for business computing needs. Memory is far more likely to be the bottleneck in my experience.
If a company has modern equipment in 95% of their locations, but the remaining 5% are difficult to upgrade for some reason (cost of disk is unlikely to be that reason), then those 5% will determine which technologies are even taken into consideration.
Asp.net, entity framework, anytime you use an attribute, binding, autogenerating columns based on an object.
[1] https://devblogs.microsoft.com/dotnet/introducing-c-source-g...
JS is also exposed to this. Some libraries can be shaken but I've always ran into random things breaking when trying it.