> For anyone interested, such a binary ends up at least 50MB

.. if you don't make any use of assembly optimisation/trimming, sure.

    $ dotnet publish -c Release
    Microsoft (R) Build Engine version 16.8.3+39993bd9d for .NET
    Copyright (C) Microsoft Corporation. All rights reserved.

      Determining projects to restore...
      Restored /tmp/ConsoleApp/ConsoleApp.csproj (in 18.97 sec).
      ConsoleApp -> /tmp/ConsoleApp/bin/Release/net5.0/linux-x64/ConsoleApp.dll
      Optimizing assemblies for size, which may change the behavior of the app. Be sure to test after publishing. See: https://aka.ms/dotnet-illink
      ConsoleApp -> /tmp/ConsoleApp/bin/Release/net5.0/linux-x64/publish/
    $ cd /tmp/ConsoleApp/bin/Release/net5.0/linux-x64/publish/
    $ ls
    total 29M

> When talking about the size required for a program to run, you have to weigh all of its dependencies.

Except the dependencies might not even be relevant depending on which OS you're targeting - and in the context of this article, why is this even interesting? You can make all of the same criticisms of the JVM, or .NET web apps or anything else - do you statically link libc?

Just to be clear, a self-contained build includes the .NET runtime and all its libraries in your build output.

Most people just install .NET on their machines. If so, that 1.4mb executable will run just fine.

The .NET framework is usually expected to be installed at the system level.

And to what extreme do you take that line of thought? Should the kernel size be included?

in my opinion it is not the greatest argument

You write:

>And you end up with a console app that is 20-100MB.

Yea, but you can also say

>And you end up with a decent size app that is 20-100MB.

and also you can say

>And you end up with a decent size app that is 2MB

because you already have runtime, because you use .NET apps.