Epic: .NET libraries are annotated to support trimming and we provide trimming guidance for library authors

[samsp-msft]

The trimming story is a journey where we are improving the capabilities release to release. With .NET 5, we have added the linker capability for trimming and started the annotation effort for the framework.

For an application to be correctly fully trimmable, we need to know all the places where dynamic code patterns such as reflection and reflection emit are used. Along with that we will provide annotations for the linker so that it knows how to find the required types so that they are not trimmed, provide a source generator equivalent, or if the functionality is inherently supportable in conjunction with trimming then to provide an error to the app developer.

Goals

• Developers should have clarity on whether the application will be trimmable
• Trimming should be possible for all mainline scenarios. Work with owners for each of the workloads to:
  • define the mainline scenarios
  • remove / mitigate issues in libraries for the mainline scenarios
  • supply representative apps for validation
• Linker should produce an error for every case where trimming will fail
• Remove "Preview" tag from the trimmer
• Enable trimming for the following app types:
  • Blazor
  • Mobile apps
  • ASP.NET
  • Console apps
  • Ideally an additional UI framework (e.g. WinForms or WPF)

Annotating the framework

This is a recursive initiative as each layer of the onion will potentially increase the surface area that can be trimmable and uncover additional APIs that need to be annotated. Decisions on which APIs should be focused on should be driven by usage stats (if we have them).

Annotating Libraries

Most customer applications make use of libraries from third parties, commonly via NuGet, those also need to be annotated for trimming. We need to provide tooling to assist the developers in determining which of their APIs need to be annotated, and how to annotate them. The current library analysis uses hidden command line switches and needed to be augmented with custom tools created by the engineer currently working on annotations. The experience needs to be exposed in Visual Studio for both library consumers and library authors, with the ability to drill into the specifics of which API dependencies are causing issues.

We will need an outreach program for library authors, and probably have a way to filter out packages that are not trimmable from NuGet searches.

AOT annotations

All the annotations for trimming also assist in native AOT scenarios, as that has the same problem with not being able to determine dependencies when reflection is used. There are some additional limitations of native AOT that needs similar annotations to the attributes used for trimming. This should be added early so that the annotation exercise can consider both scenarios.

User Stories

• Developers want to be confident that their apps run successfully when trimmed to avoid debugging trimming related problems at runtime Developers want to be confident that their apps run successfully when trimmed to avoid debugging trimming related problems at runtime #43078
• Developers can safely trim their apps which use System.Text.Json to reduce the size of their apps Developers can safely trim their apps which use System.Text.Json to reduce the size of their apps #45441

Issues

Marked with (see query)

Items not completed in .NET 6

• Developers can safely trim their apps which use Dependency Injection to reduce the size of their apps #44432
• Developers can safely trim apps which need Configuration Binder #44493
• Developers can safely trim ASP.NET apps to reduce their deployment payloads aspnetcore#27384
• Improve trimming support for EF Core apps to reduce application size efcore#21894

[samsp-msft]

Tagging: @agocke, @eerhardt, @vitek-karas , @sbomer

[samsp-msft]

We should consolidate with dotnet/aspnetcore#27384, that should probably become a child?

[vitek-karas]

To support library authors we will need to have a way to run analyzers to produce the right warnings, both in the IDE (Roslyn analyzers) as well as all up (possibly even the linker in some form).
We need a mechanism to enable the analyzers in the right cases:

• We want as many libraries to be trim compatible as possible
• We don't want to start producing lot of warnings by just upgrading

Basically dotnet/sdk#14562 but for libraries.

This applies to other scenarios like single-file, AOT and so on as well.

[jeffhandley]

@samsp-msft I updated the description to reflect what made 6.0 and what didn't. I propose that we close this and create a new epic for .NET 7 that captures the items that are carrying over, so that we can reference what was completed in 6.0 and what was cut.

[danmoseley]

Closing as we are done for 6.0.