Developers can safely trim ASP.NET apps to reduce their deployment payloads

[mkArtakMSFT]

Summary

This is a big effort to help with better trimming of the library with the goal of reducing the size of a published app.
There are some design choices we've made which make it hard to trim unused code (broadly, anything that uses reflection)
As part of this effort those designs should be reviewed to see whether we can find better alternatives.

People with more context

@davidfowl, @halter73, @javiercn, @captainsafia

Motivation and goals

This is part of a bigger plan to make the higher level frameworks trimmable (see dotnet/runtime#43543).

We also want to make sure people can host web servers as part of cloud infrastructure as small single file executables.

Longer term, we want to make sure that ASP.NET Core can work in full AOT mode without reflection and this is the first stage of that journey.

In scope

We want to make sure we can trim ASP.NET Core applications with confidence by default. Our target for .NET 6 is APIs only. This includes:

Out of scope

We're not going to focus on applications with Web Applications at the moment. Web Applications with Razor views won't be explicitly trimmable in .NET 6.

Risks / unknowns

Testing is one of the really hard things to cover when doing linking. To get 100% coverage you need to basically re-run all of the tests with the appropriate code linked.

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[danmoseley]

Adjusted title to give context in themesof.net

[Pilchie]

👀

[danmoseley]

Making this a user story to parallel the base libraries story.

[mkArtakMSFT]

Marking with both area-labels as this is a cross-cutting effort.

[danroth27]

Related issues (query based on linker-friendliness label):

• ILEmitTrieFactory isn't linker friendly #24725
• TypedHeader has linker unfriendly logic #24724
• RouteConstraints aren't linker friendly #24723
• Router.PreferExactMatches ends up limiting trimming unnecessarily #29913
• DataProtection isn't linker friendly #24705

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[mkArtakMSFT]

@JamesNK what is left to be done here? I know for Blazor we still have work to do. Is there anything else related to trimming on your side, or can I file a new Blazor-specific issue and close this?

[JamesNK]

Blazor and razor. @eerhardt youre probably closer to this than I am now. Major gaps in AspNetCore trimming/AOT story?

[davidfowl]

I think this should be closed and more specific issues can be opened.

[richard-collette-precisely]

I think this should be closed and more specific issues can be opened.

But who, that knows the specific issues, is going to file it @davidfowl ?

[davidfowl]

Doesn't matter, this issue no longer serves a purpose. Work was done in both .NET 8 and 9. If there are new specific areas of investment as part of .NET 10 then it should be filed.

[eerhardt]

For Blazor we already have:

• Make Blazor WebAssembly apps fully trimmable (dotnet/aspnetcore#49409)
• [Blazor] Enable Blazor apps running inside of ASP.NET Core to be Native AoT compiled (dotnet/aspnetcore#51598)

For SignalR, the core + JSON protocols have been made trim and AOT compatible in .NET 9. [Trimming] SignalR (dotnet/aspnetcore#41704) is still open to track the remaining 2 protocols: MessagePack and SE.Redis.

For MVC, we have [Trimming] MVC (dotnet/aspnetcore#41767).

The other areas listed under "Not Supported" on https://learn.microsoft.com/en-us/aspnet/core/fundamentals/native-aot?view=aspnetcore-9.0#aspnet-core-and-native-aot-compatibility are:

• "Other authentication" (besides JWT)
• Session
• Spa

[mkArtakMSFT]

Thanks @JamesNK, @davidfowl and @eerhardt. Closing this now. I've created two more issues:

• Make session related libraries trimmable #58787
• Make authentication libraries trimmable #58786

As for the SPA point, we don't think that area needs to support trimming.