{"id":29533,"date":"2020-08-31T13:09:11","date_gmt":"2020-08-31T20:09:11","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/dotnet\/?p=29533"},"modified":"2020-08-31T13:09:11","modified_gmt":"2020-08-31T20:09:11","slug":"app-trimming-in-net-5","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/app-trimming-in-net-5\/","title":{"rendered":"App Trimming in .NET 5"},"content":{"rendered":"

\n What is trimming\n<\/h2>\n

\n One of the big differences between .NET Core and .NET Framework is that .NET Core supports self-contained deployment \u2013 everything needed to run the application is bundled together. It doesn\u2019t depend on having the framework separately installed. From an\n application developer perspective, this means that you know exactly which version of the runtime is being used, and the installation\/setup is easier. The downside is the size \u2013 it pulls along a complete copy of the runtime & framework.\n<\/p>\n

\n To resolve the size problem, we introduced an option to trim unused assemblies as part of publishing self-contained applications. We first made assembly trimming<\/a> available as part of .NET Core 3.0. It is also sometimes called the “assembly linker”. Optionally during the publish process, a trim phase occurs which does an exhaustive walk of the code paths identifying the assemblies that are used by the code.\n It will then only package those assemblies into the app, thereby reducing the size of the application.\n<\/p>\n

\n In .NET 5, we are taking this further, and cracking open the assemblies, and removing the types and members that are not used by the application, further reducing the size. For example, for a Hello World app (dotnet new\n console<\/code>), the sizes of assemblies are:\n<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
\n

\n Assembly<\/strong>\n <\/p>\n<\/td>\n

\n

\n Trimmed (k)<\/strong>\n <\/p>\n<\/td>\n

\n

\n Member Trimmed (k)<\/strong>\n <\/p>\n<\/td>\n<\/tr>\n

\n

\n System.Collections.Concurrent.dll\n <\/p>\n<\/td>\n

\n

\n 184.9\n <\/p>\n<\/td>\n

\n

\n 23.5\n <\/p>\n<\/td>\n<\/tr>\n

\n

\n System.Collections.dll\n <\/p>\n<\/td>\n

\n

\n 85.5\n <\/p>\n<\/td>\n

\n

\n 15.5\n <\/p>\n<\/td>\n<\/tr>\n

\n

\n System.Collections.Immutable.dll\n <\/p>\n<\/td>\n

\n

\n 171.5\n <\/p>\n<\/td>\n

\n

\n 20.0\n <\/p>\n<\/td>\n<\/tr>\n

\n

\n System.Console.dll\n <\/p>\n<\/td>\n

\n

\n 61.5\n <\/p>\n<\/td>\n

\n

\n 31.5\n <\/p>\n<\/td>\n<\/tr>\n

\n

\n System.Diagnostics.StackTrace.dll\n <\/p>\n<\/td>\n

\n

\n 33.9\n <\/p>\n<\/td>\n

\n

\n 8.5\n <\/p>\n<\/td>\n<\/tr>\n

\n

\n System.IO.Compression.dll\n <\/p>\n<\/td>\n

\n

\n 88.5\n <\/p>\n<\/td>\n

\n

\n 33.0\n <\/p>\n<\/td>\n<\/tr>\n

\n

\n System.IO.FileSystem.dll\n <\/p>\n<\/td>\n

\n

\n 84.5\n <\/p>\n<\/td>\n

\n

\n 18.5\n <\/p>\n<\/td>\n<\/tr>\n

\n

\n System.IO.MemoryMappedFiles.dll\n <\/p>\n<\/td>\n

\n

\n 28.0\n <\/p>\n<\/td>\n

\n

\n 22.5\n <\/p>\n<\/td>\n<\/tr>\n

\n

\n System.Linq.dll\n <\/p>\n<\/td>\n

\n

\n 128.0\n <\/p>\n<\/td>\n

\n

\n –\n <\/p>\n<\/td>\n<\/tr>\n

\n

\n System.Private.CoreLib.dll\n <\/p>\n<\/td>\n

\n

\n 9,127.4\n <\/p>\n<\/td>\n

\n

\n 1,781.5\n <\/p>\n<\/td>\n<\/tr>\n

\n

\n System.Private.Uri.dll\n <\/p>\n<\/td>\n

\n

\n –\n <\/p>\n<\/td>\n

\n

\n 64.5\n <\/p>\n<\/td>\n<\/tr>\n

\n

\n System.Reflection.Metadata.dll\n <\/p>\n<\/td>\n

\n

\n 432.0\n <\/p>\n<\/td>\n

\n

\n 109.5\n <\/p>\n<\/td>\n<\/tr>\n

\n

\n System.Runtime.CompilerServices.Unsafe.dll\n <\/p>\n<\/td>\n

\n

\n 7.0\n <\/p>\n<\/td>\n

\n

\n –\n <\/p>\n<\/td>\n<\/tr>\n

\n

\n System.Runtime.Serialization.Formatters.dll\n <\/p>\n<\/td>\n

\n

\n 112.5\n <\/p>\n<\/td>\n

\n

\n 84.5\n <\/p>\n<\/td>\n<\/tr>\n

\n

\n Total\n <\/p>\n<\/td>\n

\n

\n 10,545.1\n <\/p>\n<\/td>\n

\n

\n 2,213.0\n <\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\n * As the commercials say, \u201cresults not typical\u201d. The size reductions above are probably better than can be expected for most real apps \u2013 the app simply outputs \u201cHello World!\u201d, so makes minimal usage of most of the assemblies. The size above is just for\n the framework assemblies, it doesn\u2019t account for the runtime which is a fixed cost that applies to every app.\n<\/p>\n

\n Trimming sounds great, but as with most good things, there is a catch. The trimming does a static analysis of the code and therefore can only identify types and members when they are referenced from code. However .NET offers a great deal of dynamism,\n typically depending on reflection. For example, Dependency Injection in ASP.NET Core uses reflection to select appropriate constructors. This is largely transparent to the static analysis, so it needs to either be told about the required types or\n be able to detect common dynamism patterns \u2013 otherwise it will trim away code that is needed by the application which will result in runtime crashes..\n<\/p>\n

\n Assembly-level trimming\n<\/h2>\n

\n To assembly-level trim, use the dotnet publish command either without a trim mode, or use <TrimMode>CopyUsed<\/TrimMode><\/code> in the project file:\n<\/p>\n

\r\n<Project Sdk=\"Microsoft.NET.Sdk\">\r\n    <PropertyGroup>\r\n        <OutputType>Exe<\/OutputType>\r\n        <TargetFramework>net5.0<\/TargetFramework>\r\n        <RuntimeIdentifier>win10-x64<\/RuntimeIdentifier>\r\n        <PublishTrimmed>true<\/PublishTrimmed\r\n        <TrimMode>CopyUsed<\/TrimMode>\r\n    <\/PropertyGroup>\r\n<\/Project>\r\n<\/pre>\n
\n    Or on the command line:\n<\/p>\n
\r\ndotnet publish -r win10-x64 -p:PublishTrimmed=True [-p:TrimMode=CopyUsed]\r\n<\/pre>\n
\n    Member-Level Trimming\n<\/h2>\n
\n    .NET 5 can take it two levels further and remove types and members that are not used. This can have a big effect where only a small subset of an assembly is used \u2013 for example, the console application above. Member-level trimming has more risk than assembly\n    level trimming, and so is being released as an experimental feature, that is not yet ready for mainstream adoption<\/em>. With assembly level trimming, its more obvious when a required assembly is missing, with member level trimming you need\n    to have exhaustive testing of the app to ensure that nothing has been trimmed that could be required.\n<\/p>\n
\n    The default for .NET 5 is to use the same conservative assembly level trimming as .NET Core 3. Further gains can be made by enabling Member-level trimming by putting TrimMode=Link in the project file\n<\/p>\n
\r\n<Project Sdk=\"Microsoft.NET.Sdk\">\r\n    <PropertyGroup>\r\n        <OutputType>Exe<\/OutputType>\r\n        <TargetFramework>net5.0<\/TargetFramework>\r\n        <RuntimeIdentifier>linux-x64<\/RuntimeIdentifier>\r\n        <PublishTrimmed>true<\/PublishTrimmed\r\n        <TrimMode>Link<\/TrimMode>\r\n    <\/PropertyGroup>\r\n<\/Project>\r\n<\/pre>\n
\n    Or passing -p:PublishTrimmed=True<\/code> and\n    -p:TrimMode=Link <\/code>to the dotnet publish command. For example the following sizes are for the YARP sample project<\/a>:\n<\/p>\n\n\n\n\n\n\n
\n
\n                    Trim Mode<\/strong>\n                <\/p>\n<\/td>\n
\n
\n                    Self Contained Linux x64 (MB)<\/strong>\n                <\/p>\n<\/td>\n
\n
\n                    Single File Linux x64 (MB)<\/strong>\n                <\/p>\n<\/td>\n<\/tr>\n
\n
\n                    No Trimming\n                <\/p>\n<\/td>\n
\n
\n                    78.9\n                <\/p>\n<\/td>\n
\n
\n                    65.3\n                <\/p>\n<\/td>\n<\/tr>\n
\n
\n                    Assembly Trimming\n                <\/p>\n<\/td>\n
\n
\n                    39.7\n                <\/p>\n<\/td>\n
\n
\n                    26.1\n                <\/p>\n<\/td>\n<\/tr>\n
\n
\n                    Member Trimming\n                <\/p>\n<\/td>\n
\n
\n                    31.5\n                <\/p>\n<\/td>\n
\n
\n                    17.9\n                <\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n    Member level-trimming also strips the\n    ReadyToRun<\/a> (R2R) code from the assemblies \u2013 the results are smaller, but application startup will be slower. See further below for more details.\n<\/p>\n
\n    Dynamic code pattern analysis\n<\/h2>\n
\n    In the context of trimming applications, there are two main concerns:\n<\/p>\n