|
|
The Nano is a Nono !
|
|
|
|
|
Code/addon signing would have really helped with that... not.
|
|
|
|
|
I have been reading Application publishing - .NET Core | Microsoft Docs[^]
I find the option of the App being self-contained pretty interesting, since once of the biggest problems with big companies is the allowance to install something, the delay with the updates and / or the mandatory updates (for yesterady of course) when they decide something has to be done (even when it might bring breaking changes with it).
I will play with both to experience myself and maybe do some detailed comparisons, but I am interested in your experiences too.
Are you using the self-contained option? If, not...why? It looks very promising.
Is the difference in size really that big?
Have you noticed performance differences when using one or the other? And I don't mean the startup-time described in the "ReadyToStart" option, I mean while in the middle of the execution.
Topic open to discussion 
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.
|
|
|
|
|
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 was thinking I was only calling a few jQuery methods on my webpage but my users have to download all jQuery even 99% of functionality is not used. What a waste of bandwidth!
|
|
|
|
|
A long time ago I did this weird "site on a business card CD**" where the javascript was gzipped and decompressed itself (and all the HTML content as well) - I suppose you could do something like that, but these days it's probably not worth the effort.
** not sure if you've ever seen these - it's a partial CD roughly the size of a business card and will spin in most CD trays. The inner tracks have space for enough data to fit a small bit of media or even an app on.
Real programmers use butterflies
|
|
|
|
|
50 Mb?[^] - Holy Batman! The possibilities are endless! 
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark Twain
|
|
|
|
|
I thought it was less. Oh well, it has been a long time.
Real programmers use butterflies
|
|
|
|
|
For us perhaps. For real Javascriptors that may or may not be enough for Hello World.
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.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
