|
Shao Voon Wong wrote: Hopefully, the .NET team can take a leaf from the Visual C++ team to get the executable size down. C++ does not link the unused classes and remove the methods not called at all (directly or indirectly) from the executable.
I think they have already done that
dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true /p:PublishTrimmed=trueThat should deprecate what is not used.
In a simple hello world console reduces the memory needs from 69 to 29 Mb
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
29MB is still too much for a Hello World program. That PublishTrimmed=true should be made mandatory, not as opt-in.
|
|
|
|
|
Reflection makes it somewhat difficult to make this mandatory. Stuff like "Register all classes in this assembly/namespace with the DI container, "deserialize this JSON looking up the types based on the $type property" is all over the place.
So at least they need to add the option to specify what always needs to be included, and this would need to work across dependencies. Not impossible, but I can see how it would end up in the "something for the next version" pile. At least they can keep the signature of the classes they stripped out, so any reflection code hitting them could give a meaningful error. A proper error message is worth more than 1MB or two in my book. 
And I guess when the choice was between the comments saying "this does not work" and "this is too big", they chose the latter in the default settings. Can't say I blame them...
|
|
|
|
|
Shao Voon Wong wrote: 29MB is still too much for a Hello World program.
Maybe there are 28.5 Mb Framework and only 500kb "Hello World", that's actually the point of it.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
|
Not a waste of bandwidth if you used the official JQuery 3.5.1 CDN. Most people would have a copy cached on their browsers already. Unless you host JQuery on your own server.
|
|
|
|
|
If it's a UWP app, you can distribute it (corporately) through the Windows store, including forced updates.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
I am not concerned about the dustribution of "my" app, but the distribution of the windows updates and / or frameworks that could break the proper functioning of the app.
If everything needed is included in the exe, then the App should still be able to run, even when i.e. the .Net Framework was deinstalled or changed
We had the situation that the IT just rolled out a new version of the Java runtime and a couple of things stopped working, then the java guy had to run to make that work again.
I see the problem if a lot of software did this, but for a single App... I personally find it a real improvement. There are downsides too i.e.
Quote: .NET Core will update critical security patches as needed for the framework library in the machine that your app runs on. You are responsible for end to end validation for this security patch scenario.
but that happens with separated runtime too.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Your app's manifest says what Windows builds and frameworks it supports. Your app doesn't get automatically updated to a newer version.
The Java Runtime is another matter and not part of any typical .NET distribution. Same goes for any third part library that needs to be "shared".
You have a Java Runtime distribution problem; not a .NET "app" problem.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Gerry Schmitz wrote: Your app doesn't get automatically updated to a newer version.
It is not the App update what I worry.
The .Net Framework in the local system comes and goes depending on domain policies pushed by the IT department.
I know the MS people have done a pretty good job with backwards compatibility in .Net Framework, but it won't the first time (and since windows 10 is out there it happens damned more often) that a Windows Update breaks some things.
This is the reason because I see this possibility as promising. But I am still realistic and I think that it probably blow up my expectations in unexpected ways.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
The big question is what 'self contained' is supposed to mean. I doubt that they will go as far as letting you throw the program plus a generic bootloader on a computer without any OS installed. That could be done, but it would mean that you have to include a minimal OS and drivers. That would put you only one step away from the good old hardware dependency hell.
Both updating hell and framework hell are only additional circles of DLL hell. The only solution has always been to include required DLLs into the program and not use whatever versions are installed. That defeats many purposes of dynamic linking and may put you in some other hells, but it's the only way out.
I guess, 'self contained' will only mean independency from any installed .NET frameworks and not more. So framework and update hell get a little better, but you the other circles of DLL hell also get a little more interesting again. This is not progress. It's the admission of defeat.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
CodeWraith wrote: This is not progress. It's the admission of defeat.
Interesting point fo view.
I suppose I will learn it in the bad way. Because I am thinking on using it in my next project.
It is to try it and make it as much portable as possible and "future oriented" or to do it in the lowest .Net Framework that I find in a big serie of non-standard PCs in small isolated local networks which might still be a pretty old version of the .Net Framework.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: I suppose I will learn it in the bad way. Because I am thinking on using it in my next project.
Go ahead and do that. I just don't expect it to help very much. You can't eliminate DLL hell without forfeiting the benefits of dynamically linked libraries.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
CodeWraith wrote: ou can't eliminate DLL hell without forfeiting the benefits of dynamically linked libraries.
I know, but lucky me, the App is a relative small (in comparison with other projects) closed system where I don't expect to need interaction with external dlls, only the standard Framework things.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I've seen entire OS's smaller than a .NET Core standalone self-contained binary - So I wouldn't put it past them...
-= Reelix =-
|
|
|
|
|
In the case of .Net Core 3.1 and up, it means that all the required assemblies(.Net Core and third-party) are included in the same folder, so that your application is not relying on any installed framework on the destination computer. You can also go one step further and have it compiled into a single executable, and you can also specify to trim which assemblies are needed(although experimental with 3.1, and didn't work for all scenarios, but should be out of the experimental phase for 5.0). And, they are supposed to be working to further enhance the trimming feature, so that it is only the required code that gets compiled, instead of the whole assembly, but not sure when this will be ready.
And, we've been using the .Net Core 3.1 self-contained executable feature in production, since the release of .Net Core 3.1, without any problems.
Daniel
|
|
|
|
|
|
That's a good argument, thanks.
Dan Neely wrote: If every application has its own copy of the affected library,
It would be not "every" it would be "only one".
The point is that we have a requirement "to avoid having to install things" (and yeah, for them, the .Net Framework would be something to be avoided if possible)
So... it is a bit like if I do... bad, but if I don't do... worse.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I know that feeling. About a decade ago, a customer decided they wanted to offer a capability my then employer helped create to a third party; but they were terrified of being reverse engineered. We ended up not just all in one packing (via a 3rd party tool) a winform app; but running it through an obfuscate and encrypt tool as well. Before we managed to convince their paranoids to sign off on that, we'd been contemplating having to port the entire application to C++/MFC like the rest of the tools that were part of the package being offered. 🤮
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Nelek wrote: Have you noticed performance differences when using one or the other? And I don't mean the startup-time
Well..
Nelek wrote: Topic open to discussion 
Apperently not. May you find the answers that do please you.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Quote: Is the difference in size really that big?
Yes - Yes it is.
A basic standalone self-contained single file "Hello World!" app is like 75MB. A Hello World .NET Framework .exe is 4kb.
-= Reelix =-
|
|
|
|
|
Reelix wrote: A basic "Hello World!" app is like 75MB. A Hello World .NET Framework app is 4kb.
Yeah, I found a bit later some comparisons, in the case I saw it was 69 Mb with standard self deployment and then 29 Mb with "only the needed" self deployment (see above)
Reelix wrote: A Hello World .NET Framework app is 4kb.
But the .Net framework itself is several hundred of Mb (I know, I know general purpose and share-used by everything else too)
I wonder how much of that .Net Framework is strictly needed to run that 4 Kb "Hello World"
And please note that I am not defending the self deployment, I just want to point out that it might be not such a big difference from one to another if we consider it as a whole.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Sure - The .NET Framework itself is several hundred MB - But think long-term.
You need to do 75 deployments over 1-5 years to a single company.
Do you want to
a.) Do 1 * large deployment and multiple ones that copy / deploy instantly
OR
b.) Do 75 medium-size deployments
Now, let's say that the recipient company is in your average third-world country, and has 50kb/s upload. Still think the once-off largish setup (That - Keep in mind - Most modern devices already have installed by default, or are simple to acquire locally) is still worse?
Similarly, go into your Windows / Program Files folder (On Windows). Search for *.exe or *.dll. Now, imagine every single one of those files was upgraded to the new format, and was at least 50MB (Or 29MB, using your above trimmed estimation). Would your current OS drive still be able to contain your OS?
-= Reelix =-
|
|
|
|
|
This are very good points and I agree with you in all.
But in my case, that doesn't apply (I don't want to repeat me, so I ask you to read the other messages)
TL;DR; Specs asking for needing the less "extra" installations as possible (and sadly .Net Framework is included in that cathegory) plus a messed up mix of different versions in the places where it is already installed.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Unsuited containing harmony (12)
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
