Unnecessary dlls are shipped in Blazor WebAssembly

user_2194443 0
Viewed 2422

I'm trying to use Blazor WebAssembly hosted by ASP.NET Core. After implementing a page, I saw in Chrome DevTools many of unnecessary dlls are transmitted to client. There is an example of situation. Let's assume we have following structure of projects in the solution:

BlazorApp.Client (contains Blazor pages)
    Reference to BlazorApp.Shared
BlazorApp.Server (contains ASP.NET core)
    Reference to BlazorApp.Client
    Reference to BlazorApp.Shared
BlazorApp.Shared (contains shared classes)
    Reference to ClassLibrary
ClassLibrary (contains some more shared classes)
    NuGet reference to AWSSDK.Core
    MyEnum.cs (enum, which is used in Blazor page; not using AWS SDK)

So basically BlazorApp.Shared project has reference to some other project, which could have many nuget packages. Minimum code to reproduce the issue is available in repo https://github.com/GTmAster/blazor-treeshake

My assumption is Mono Linker does a tree shaking in Release build, so all unused code and libraries will be excluded from resulting web assembly. But when I run my app, I see it loads AWSSDK.Core.dll from the server: DevTools Code in BlazorApp.Client doesn't used it, as well as the code in BlazorApp.Server and in BlazorApp.Shared. It is only loaded, because it is referenced in ClassLibrary.

Am I getting the wrong idea about Mono Linker tree shaking? Is the only way to exclude this dll from shipping is to move MyEnum to BlazorApp.Shared and break BlazorApp.Shared -> ClassLibrary reference?

blazor c#
2 Answers

You are right, the mono linker is tree shaking.

The only relevant information I could find is here: https://devblogs.microsoft.com/aspnet/blazor-webassembly-3-2-0-preview-2-release-now-available/

You may notice with this preview release that the download size of the app during development is now a bit larger, but build times are faster. This is because we no longer run the .NET IL linker during development to remove unused code. In previous Blazor previews we ran the linker on every build, which slowed down development.

So as it is stated:

Now we only run the linker for release builds, which are typically done as part of publishing the app.

Are you looking into release builds?

Try following the this advise if you want tree shaking in debug builds.

If you prefer to still run the .NET IL linker on each build during development, you can turn it on by adding <BlazorWebAssemblyEnableLinking>true</BlazorWebAssemblyEnableLinking> to your project file.

user_16436760

I've been investigating this too. It seems that the Linker doesn't do what you expect it to.

https://github.com/dotnet/aspnetcore/issues/28546#issuecomment-742100867

By default Blazor (and all of .NET Core) does not trim application code, it only trims the framework. There are patterns of code that are problematic with trimming. The runtime libraries have been updated and tested to make sure they play well with trimming, arbitrary libraries or user code might not be.

Upon further digging, it seems like you'd need to use Trimming to get further reductions in size. But I found this article, which at the bottom states:

The following trimming approach is being taken for Blazor Apps in .NET 5:

  • Assemblies from the shared framework/runtimepack get member-level trimming
  • Microsoft.Extensions.* assemblies get type-level trimming from TrimMode=Link
  • Assemblies from Microsoft.AspNetCore.* are trimmed via hand generated XML file
  • All other assemblies are not trimmed

All in all means that the Linker / Trimming isn't going to remove unused assemblies as that's not what it does. It essentially just trims stuff out of the Framework assemblies that it believes you do not need.

user_8681590
Related