Runtime: Reduce necessary DLLs footprint

[forestbat]

Let's see this picture which is a hello world app trimmed by IL linker。
We can see System.Private.CoreLib is the biggest，about 10MB，and some necessary dlls such as coreclr，mscordbi are also a little big，so I think it's important to reduce their size or split them to smaller pieces.

[AaronRobinsonMSFT]

cc @swaroop-sridhar @jeffschwMSFT @vitek-karas

[swaroop-sridhar]

CC: @sbomer

[swaroop-sridhar]

Related issue: dotnet/runtime#12629

[vitek-karas]

I just want to point out that this automatically assumes that self-contained app is necessary. It's very possible that in your scenario that is the case, but maybe not. Note that framework dependent apps are "MUCH" smaller - no amount of ILLinker will be able to get the app to the size of framework dependent app.

[forestbat]

@vitek-karas Framework dependent apps still need cost at least 70MB space on disk，doesn't it？
@AaronRobinsonMSFT @swaroop-sridhar @cup @sbomer @jeffschwMSFT
IL linker works like -jlink in Java9，however the largest piece of a trimmed JRE is jbase——it's 17MB！With CoreCLR's changing，Corelib may be larger and larger until it become a new “jbase”，it's not a good future。
And I'm a player of Minecraft Java Edition，I‘m bored of telling newcomer of the game how to download JRE or JDK from Oracle.com/java.com，especially today we must register oracle account or search openjdk——in many scenes consumers are foolish，they don't want to care how to download a big dependence，what they want is a simple little single file，and I think if a product can be used by foolish happily，it will be successful。
Although this is a big project，it has benefit for future。Please think it over。

[AaronRobinsonMSFT]

@forestbat Yes the disk cost will still be 70 MB. @vitek-karas's point is that it can be a one time cost shared across all potential applications. If the machine will have multiple .NET applications using the same framework then the cost can be shared across all of them since each one will use the same CoreCLR. If however there is only a single program using CoreCLR then the cost isn't shared and much higher ratio per application.

In the scenario mentioned, a complete standalone to reduce users from having to download prerequisites the shared framework, we just need to keep finding ways to reduce the size to those kind of scenarios can be better. Thank you for bringing up this example it is helpful to have concrete scenarios and this one makes a clear case.

[forestbat]

And this is WPF app which has been trimmed，PresentationCore will probably be killed by anti-virus。

This is ASP.NET Core app which has been trimmed。

[clairernovotny]

I would love to see a significant reduction in the final trimmed size as well. Not sure what the right mechanism is yet (more aggressive trimming of the private corlib, splitting into different modules, something else?). This also plays into the single-exe AOT story.

[forestbat]

@onovotny I think splitting into smaller modules and reduce footprint of every dll are better than trimming dlls more aggressively，because trimming a full assembly will probably generate no-standard dlls and bring some trouble。
AOT such as Mono AOT or CoreRT can largely reduce the assembly，however it will lose syntax such as generic and we probably wait for compiling like C++。

[tomrus88]

I'm still not sure why they have 2 copies of mscordaccore.dll in output (mscordaccore.dll and mscordaccore_amd64_amd64_4.700.19.31301.dll). Both dll's are identical content wise, just different name...
Easy size reduction by 1.2MB and -1 dll by removing one of them...

[0xd4d]

@tomrus88 most people who trim their apps probably don't want any of the debugger related files at all so they shouldn't even be there. DiaSymreader shouldn't be needed either since anyone who trims their app surely won't include the PDB files, and even if they did, they'd be portable PDBs not Windows PDBs.

[forestbat]

@AaronRobinsonMSFT Will this issue be added in 3.0 next milestone？

[AaronRobinsonMSFT]

@forestbat This issue will continue to get focus in future milestones. Both @sbomer and @swaroop-sridhar are actively working in this area to improve ILLinker scenarios to reduce managed binaries size in self-contained applications. One of them would have to comment on approaches being taken to reduce the native binary size. The question of whether we ever satisfy everyone's desires on size is another matter, but please continue to file specific issues and they will get prioritized against other issues.

@tomrus88 and @0xd4d both mentioned binaries that could be removed. @jeffschwMSFT, @sbomer, or @swaroop-sridhar do any of you know who from the diagnostic side of things is working on removing DAC and symbol reading binaries from the self contained scenario?

[sbomer]

@mikem8361 would you mind commenting on the question about removing diagnostics binaries?

[mikem8361]

sos.dll and sos_*.dll can be removed. SOS is now shipped/installed out of band.

The DAC (mscoredaccore.dll) and DBI (mscordbi.dll) DO need to be included to support managed debugging.

[sbomer]

Thanks! Is someone on the diagnostics team working on removing the unnecessary dlls from the runtime packages?

[mikem8361]

I don’t think we were aware that the diagnostics team was supposed to do anything.

@tommcdon

[forestbat]

@cup Of course it's native.
https://github.com/dotnet/coreclr/issues/24397#issuecomment-489391079
And 1.5M is the limit of a C# app，in this size coreclr won't exist and C# will lose almost all features of itself，I think MS want a small but contains many "normal" function of C# and CLR.
However I think a hello world app should be at most 10MB.

[tomrus88]

@cup Repo you linked is C# on .NET Framework. You can do the same on .NET Core by installing .NET Core runtime on target system manually and publishing your app as "framework dependent"... It will have size similar to .NET Framework app size, very small.

So you have to choose between:

• big apps and not having to install runtime (.NET Core self contained apps)
• small apps, but need to install runtime separately (.NET Framework or .NET Core Framework dependent apps).

[ghost]

@tomrus88 where is the dotnet.exe for .NET Framework? where is that repo?

[tomrus88]

@cuo .NET Framework doesn't have or need dotnet.exe.

[vitek-karas]

In .NET Framework one of the jobs of the dotnet.exe is handled by the OS. Windows "knows" about .NET applications and will ask the installed .NET Framework to run the app if a managed executable is started as a process. This means that there was a small component which was part of the OS. We didn't want to do that in .NET Core as it's hard to service such component (and there's really no counterpart on Linux/Mac anyway).

The other things dotnet.exe can do, like dotnet build and similar SDK operations didn't have a counterpart on .NET Framework (I guess msbuild, but it's not the same). Note that you can use dotnet build and other SDK commands to work with .NET Framework projects now though.

[forestbat]

About 1 month passed，will it has some change in .NET 5？

[vitek-karas]

We've been focusing on finishing 3.0. There are no firm plans for 5 yet, but I think making single-file smaller will be part of it.

[forestbat]

dotnet/coreclr#26175 I saw this issue，will structure of dotnet's packages change？

[jeffschwMSFT]

@forestbat feel free to comment on the main thread, there are no anticipated changes to the packages due to the repo consolidation.

[yyjdelete]

https://github.com/dotnet/coreclr/issues/25153#issuecomment-502396024
Is anyone still active on this and know why something like mscordaccore_amd64_amd64_4.700.19.45506.dll is still needed?
It's the same as mscordaccore.dll, and seems not be referenced by any files in the publish folder.

[jkotas]

mscordaccore_amd64_amd64_4.700.19.45506.dll is still needed?

It is needed for dump debugging. It should not be needed in published self-contained apps. cc @dotnet/dotnet-diag

Note that there are number of other files like this. For example, none of the *.a files in the self-contained apps published for Linux are needed.

@sbomer Do you have thoughts on what would be the best strategy to get these one-off unmanaged files trimmed from the self-contained apps?

[0xd4d]

All debugger related files don't need to be included. They just add space and almost no-one needs them. Those that need them can easily find those files. DiaSymreader shouldn't be included either.

[jeffschwMSFT]

@sbomer Do you have thoughts on what would be the best strategy to get these one-off unmanaged files trimmed from the self-contained apps?

Trimming native components did not make .NET Core 3. But it is part of our plans for an upcoming release.

[ghost]

Another option is Roslyn:

~~~
C:\microsoft.net.compilers.3.3.1> type sun-mon.cs
using System;
class Program {
static void Main() {
Console.WriteLine("sunday monday");
}
}

C:\microsoft.net.compilers.3.3.1> tools\csc.exe sun-mon.cs
C:\microsoft.net.compilers.3.3.1> sun-mon.exe
sunday monday

C:\microsoft.net.compilers.3.3.1> dir sun-mon.exe
2019-11-16 11:34 PM 3,584 sun-mon.exe
~~~

https://nuget.org/packages/Microsoft.Net.Compilers