Developers want to be confident that their apps run successfully when trimmed to avoid debugging trimming related problems at runtime

[agocke]

In 5.0 we introduced linker capability to warn about code and patterns which are not trimming safe. We will build on top of that feature to resolve all warnings in our core SDKs to allow developers to enable this linker capability for their code and 3rd party libraries to give them confidence that trimming does not alter their app behaviour unexpectedly.

We'll also work on further enhancing the warning user experience to give the developers feedback about potential problems in their app as early as possible.

The primary goal for .NET6 is to have all linker related warnings resolved for core SDKs for all workloads which use publish with trimming enabled by default. In particular following workloads

• Blazor Client/WebAssembly
• Mobile iOS/tvOS (Xamarin.iOS)
• Mobile Android (Xamarin.Android)
• macOS UI (Xamarin.Mac)
• Hybrid Blazor (optional)

Work Items

• Regression test for console app warnings Verify linker warnings for "Hello, world" sdk#13994
• Linker lazy loading Change referenced assemblies processing to be on demand in MarkStep linker#1164
• Support for startup hook feature Handling of startup hooks in linked applications #36526
• Add analyzers for all linker warnings
• List and categorize all netcoreapp linker warnings Categorize linking warnings for netcoreapp #44035
• Fix warnings in .NET Libraries Fix ILLink warnings in .NET Libraries #45623
• End-to-end experience for "publish feature" analyzers including trimming Analyzers for publish only functionality sdk#14562
• Default values for feature switches in trimmed console apps Default values for feature switches in trimmed console apps sdk#14475
• EventSource linkability
• COM linkability Add the ability to remove COM support using ILLinker #36659
• Mitigations for DCS DataContractSerialization is not linker friendly #36154
• Mitigations for Xml serializer XmlSerializer.Serialize doesn't work when using TrimMode=link #41389
• Trimming tests for all configurations Libraries trimming test are missing a lot of configurations #39274

Partner dependencies:

• Roslyn support for suppression using UnconditionalSuppressAttribute Request: Treat UnconditionalSuppressMessageAttribute like SuppressMessageAttribute roslyn#48885
• Roslyn support Flow attributes on generic types to compiler generated constructs Flow attributes on generic types to compiler generated constructs roslyn#46646

MaciOS

• [.NET 6] Linker may not preserve exported methods with overrides xamarin/xamarin-macios#11449
• [.NET 6 linker] Keep wrapper types referenced from ProtocolAttribute xamarin/xamarin-macios#11985
• [.NET 6] Enable the sealer optimization in the linker xamarin/xamarin-macios#9573
• [.NET 6] Enable the metadata reducer optimization in the linker xamarin/xamarin-macios#9612

[danmoseley]

@eerhardt this would be the parent story for most of your v-team's work -- any sub work items can be children of this (they will appear in themes tree) or at least checkboxes in this or a child issue similar to what we did for Nullability annotations. When you are ready to can you please link such child items, etc so all necessary work is represented here or in its children?

[eerhardt]

at least checkboxes in this or a child issue similar to what we did for Nullability annotations

For the ILLink warnings burndown, I've created #45623 (which is linked above). It will be used to check off assemblies as we get them ILLink warning "clean".

[marek-safar]

Changed priority to P0 to align with Xamarin needs

[danmoseley]

@agocke I have marked this 'committed'. LMK if that's not correct but surely it is. There may be some of the child work items that are aspirational but we are committed to this story

[smagurauskas]

Is there a plan to make trimming feature available not only for self-contained deployments?

[marek-safar]

@tomkaa what would be the scenario where you would like to use the trimming?

[smagurauskas]

@marek-safar For example: I am developing ASP.NET Core application which has some NuGet packages installed and use framework-dependent deployment model. Some of the assemblies from NuGet are only used as middleware for local debugging. I have these middleware registrations surrounded with #if DEBUG, so in Release build these assemblies are technically not referenced anywhere, but I still have them in csproj so they get copied anyway. Current solution is to surround the <PackageReference ...> with <ItemGroup> and add Condition attribute that includes it only when configuration is DEBUG. However I think it would be great quality of life improvement if these could be trimmed automatically, even for framework dependent deployment.

[eerhardt]

@agocke - do you think this issue can now be closed? The only issue under "Work Items" that is still open is #39274. We can track adding other platforms in that issue.

[agocke]

Yup, I think this is ready to close.