Scott Hanselman

Experimental: Reducing the size of .NET Core applications with Mono's Linker

August 29, 2017 Comment on this post [13] Posted in DotNetCore
Sponsored By

The .NET team has built a linker to reduce the size of .NET Core applications. It is built on top of the excellent and battle-tested mono linker. The Xamarin tools also use this linker so it makes sense to try it out and perhaps use it everywhere!

"In trivial cases, the linker can reduce the size of applications by 50%. The size wins may be more favorable or more moderate for larger applications. The linker removes code in your application and dependent libraries that are not reached by any code paths. It is effectively an application-specific dead code analysis." - Using the .NET IL Linker

I recently updated a 15 year old .NET 1.1 application to cross-platform .NET Core 2.0 so I thought I'd try this experimental linker on it and see the results.

The linker is a tool one can use to only ship the minimal possible IL code and metadata that a set of programs might require to run as opposed to the full libraries. It is used by the various Xamarin products to extract only the bits of code that are needed to run an application on Android, iOS and other platforms.

I'll add this line to a nuget.config in my project's folder. Note that NuGet will inherit global settings and ADD this line.

<?xml version="1.0" encoding="utf-8"?>
<add key="dotnet-core" value="" />

Then I'll add the IL Linker's NuGet package to my project with this command line command (or from Visual Studio):

dotnet add package ILLink.Tasks -v 0.1.4-preview-906439

The assemblies will automatically be "trimmed" when they are published (not built) so I'll build it twice, disabling it with a switch:

D:\github\TinyOS\OS Project>dotnet publish -c release -r win-x64 -o notlinked /p:LinkDuringPublish=false
Microsoft (R) Build Engine version 15.3 for .NET Core

TinyOSCore -> D:\github\TinyOS\OS Project\bin\Release\netcoreapp2.0\win-x64\TinyOSCore.dll
TinyOSCore -> D:\github\TinyOS\OS Project\notlinked\

D:\github\TinyOS\OS Project>dotnet publish -c release -r win-x64 -o linked
Microsoft (R) Build Engine version 15.3 for .NET Core

TinyOSCore -> D:\github\TinyOS\OS Project\bin\Release\netcoreapp2.0\win-x64\TinyOSCore.dll
TinyOSCore -> D:\github\TinyOS\OS Project\linked\

And here's the results:


You can also run it with  /p:ShowLinkerSizeComparison=true and get a nice table. I've trimmed the table as it's super long.

  TinyOSCore -> D:\github\TinyOS\OS Project\bin\Release\netcoreapp2.0\win-x64\TinyOSCore.dll
Before linking (B) After linking (B) Size decrease
----------- ----------- ----------- -----------
Total size of assemblies 48,025,824 16,740,056 65.14%
----------- ----------- ----------- -----------
TinyOSCore.dll 36,352 36,352 0.00%
Microsoft.Extensions.Configuration.dll 24,584 24,584 0.00%
Microsoft.Extensions.Configuration.Abstractions.dll 20,480 20,480 0.00%
Microsoft.Extensions.Configuration.Binder.dll 24,064 24,064 0.00%
Microsoft.Extensions.Configuration.FileExtensions.dll 22,528 22,528 0.00%
Microsoft.Extensions.Configuration.Json.dll 24,072 24,072 0.00%
Microsoft.Extensions.DependencyInjection.dll 46,600 46,600 0.00%
Microsoft.Extensions.DependencyInjection.Abstractions.dll 35,336 35,336 0.00%
Microsoft.Extensions.FileProviders.Abstractions.dll 17,920 17,920 0.00%
Microsoft.Extensions.FileProviders.Physical.dll 31,240 31,240 0.00%
Microsoft.Extensions.FileSystemGlobbing.dll 39,432 39,432 0.00%
Microsoft.Extensions.Options.dll 26,120 26,120 0.00%
Microsoft.Extensions.Options.ConfigurationExtensions.dll 16,904 16,904 0.00%
Microsoft.Extensions.Primitives.dll 33,800 33,800 0.00%
Newtonsoft.Json.dll 639,488 639,488 0.00%
Microsoft.CSharp.dll 1,092,096 392,192 64.09%
Microsoft.VisualBasic.dll 465,416 0 100.00%
Microsoft.Win32.Primitives.dll 18,968 4,608 75.71%
Microsoft.Win32.Registry.dll 85,008 0 100.00%
SOS.NETCore.dll 54,264 0 100.00%
System.AppContext.dll 14,336 2,560 82.14%
System.Buffers.dll 14,336 2,560 82.14%
System.Collections.Concurrent.dll 206,360 31,744 84.62%
System.Collections.Immutable.dll 2,378,264 0 100.00%
System.Collections.NonGeneric.dll 96,792 24,576 74.61%
System.Collections.Specialized.dll 88,608 15,360 82.67%
System.Collections.dll 326,664 52,224 84.01%

TinyOSCore -> D:\github\TinyOS\OS Project\bin\Release\netcoreapp2.0\win-x64\publish\

You can see in some places where there's no size decrease. That's because I'm using those assemblies completely. Some see a 100% decrease - they've been removed entirely - because I'm not using the Registry, for example. And some see a fractional decrease because I'm using some methods but not others.

You can check out the full instructions and try this yourself at Again, it's a work in progress.

Sponsor: Check out JetBrains Rider: a new cross-platform .NET IDE. Edit, refactor, test and debug ASP.NET, .NET Framework, .NET Core, Xamarin or Unity applications. Learn more and download a 30-day trial!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
August 30, 2017 0:05
This is brilliant. I can't wait to test this out
August 30, 2017 1:07
I see the benefit but, with space being so cheap, is there a specific use case for doing this today? Or is this more a benefit that we will all inherit via Visual Studio in the future?
August 30, 2017 2:04
@Jason, start thinking about stuff like Docker containers. In the microservices world, you could have 10, 20, 30 different .NET core images, one for each microservice or application. Prior to this, each one would have those complete sets of DLLs. Now imagine the network transfer time of repeatedly downloading those images from repo to client. Or memory when loading an assembly. Or cost of storage and/or data transfer in the cloud.
August 30, 2017 9:48
@Jason: for example, we work on industrial automation, where hard disks are generally as small as possible - think less than 10 GB, with Windows (LTSB) taking a big chunk of it. What remains is pretty valuable to us...
August 30, 2017 11:46
@Jason - Good points from other, I would just like to add two points:
1. Mobile apps (storage on mobile phones is limited and expensive)
2. Optimize because you can :)
August 30, 2017 11:50
Why would this not be the default publishing mode for any project?
August 30, 2017 12:14
How does this act with reflection code?
August 30, 2017 13:10
@Mladen look here
August 30, 2017 15:59
>>> Why would this not be the default publishing mode for any project?

Probably because it's still a work in progress. Given some time, I'm willing to bet it will become part of the regular publishing process.
August 30, 2017 22:49
Example for creating a docker image with the self-contained program are here:

The reason this isn't the default, at least for docker images, is that having N different programs in N containers would also each have N copies of the necessary assemblies.

If you instead had a common base docker layer with the core assemblies (like .NET Core 2.0 does) then that single copy on disk is shared across all images.

SO... if you have a single program in a container and no additional containers then this will likely be a win for you (smaller individual container).

BUT... as you add more programs in containers that could share a base layer you're better off using the dotnet or aspnetcore base layer and just add your program on top of that (base layer will be pulled once and only the small program updates will need to be pulled per container).
August 31, 2017 16:17
The assemblies will automatically be "trimmed" when they are published (not built) so I'll build it twice

You probably meant "so I'll publish it twice".
September 01, 2017 10:24
Brought back memories of static linking, actual .lib projects (not DLLs) and whole program optimization in the late 1980s; all of which existed in the 1970s.

Unfortunately, .net prevents creating a .Lib project where methods in the .lib are included in the application compiled against the .lib. Unlike a DLL which is a different file to be managed, stored, packaged, ...

How much extra work, such as code attributes, does it need to not remove the 100s of ASP.NET MVC controller methods which Visual Studio detects as unused?

Our larger systems have upwards of 1 code attribute line for every 20 lines of non-attribute based code. Ugly, and an anti-pattern mainly from EF.

September 11, 2017 18:34
This sounds great, especially for micro services etc

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.