You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Hello world generates 45MB with publish command #6979
using System;
namespace ConsoleApplication
{
public class Program
{
public static void Main(string[] args)
{
Console.WriteLine("Hello World!");
}
}
}
And run dotnet publish -c release.
Expected behavior
Generates binary + files worth of several hundreds of KB or maybe 1MB.
Actual behavior
Bundles 45MB of files, including classics like System.Security.Cryptography.X509Certificates.dll for a safer Hello World (hi NSA!).
Environment data
dotnet --info output:
.NET Command Line Tools (1.0.0-preview2-003131)
Product Information:
Version: 1.0.0-preview2-003131
Commit SHA-1 hash: 635cf40e58
Runtime Environment:
OS Name: Mac OS X
OS Version: 10.11
OS Platform: Darwin
RID: osx.10.11-x64
Appendix
I'm wondering if there are plans to reduce the size of the generated output and if so what's the expected schedule. Also wondering if it is possible to use dotnet to generate statically lined binaries, aka single file distribution. Not necessarily statically linked in the sense of C low level linkage, but maybe an official way to bundle those .dll into fewer files like python's zip bundle tricks which allow one (at least on unix) to bundle everything into a single file.
If you use framework-dependent deployment, the application has 5 KB.
If you use self-contained deployment for OS X and specify you want all of Microsoft.NETCore.App, it's indeed 45 MB.
If you use self-contained deployment for OS X and manually specify you want only the dependencies you really need ("Microsoft.NETCore.DotNetHostPolicy": "1.0.1", "Microsoft.NETCore.Runtime.CoreCLR": "1.0.2", "System.Console": "4.0.0"), then it's 26 MB and I'm not sure which of the remaining files could be removed.
.Net Core roadmap (though I think it's not completely up-to-date anymore) says that "dotnet publish will publish only required dependencies, for optimal distribution size", so there are plans to make this easier (and possibly better).
I'm certainly interested in the self-contained deployment options. Framework-dependent deployment is far too hard for OSX users to perform, as far as I understand they would require admin priviledges and type commands into a terminal (a brew less installer would help).
I have a mono project using graphic libraries which is able to pack everything (except C dynamically linked libraries) into a 6.6MB binary, so I had high hopes about core dot net being smaller or capable of building less heavy binaries. 26MB still sounds far away at the moment.
Activity
svick commentedon Oct 15, 2016
This depends on the kind of deployment you're using.
If you use framework-dependent deployment, the application has 5 KB.
If you use self-contained deployment for OS X and specify you want all of
Microsoft.NETCore.App, it's indeed 45 MB.If you use self-contained deployment for OS X and manually specify you want only the dependencies you really need (
"Microsoft.NETCore.DotNetHostPolicy": "1.0.1", "Microsoft.NETCore.Runtime.CoreCLR": "1.0.2", "System.Console": "4.0.0"), then it's 26 MB and I'm not sure which of the remaining files could be removed..Net Core roadmap (though I think it's not completely up-to-date anymore) says that "
dotnet publishwill publish only required dependencies, for optimal distribution size", so there are plans to make this easier (and possibly better).gradha commentedon Oct 15, 2016
I'm certainly interested in the self-contained deployment options. Framework-dependent deployment is far too hard for OSX users to perform, as far as I understand they would require admin priviledges and type commands into a terminal (a brew less installer would help).
I have a mono project using graphic libraries which is able to pack everything (except C dynamically linked libraries) into a 6.6MB binary, so I had high hopes about core dot net being smaller or capable of building less heavy binaries. 26MB still sounds far away at the moment.
Thanks for the info, I'll keep lurking.
Fix false-flag of CompareExchange and re-usage with loops (#6979)