Epic: Make .NET a good choice for environments that require single file and AOT

[samsp-msft]

This is a draft/proposed Epic and not committed for .NET 6.0 yet.

Why

.NET 5 introduced more incremental improvements for applications to realize faster startup times and smaller exe sizes using single file and app trimming. As we look ahead on how we continue to make .NET a compelling platform for developers to build their modern apps on, we need to continue to evolve the platform by building on top of what .NET 5 has brought to the ecosystem. AOT in particular, is an area where we need to start to make more investments, which will likely span across several upcoming releases of .NET. Many developers want a specific solution when they refer to “AOT.” They want a solution that has the following characteristics: extremely fast startup, no IL present (for size and obfuscation reasons), a JIT is (at most) optional, and binary size is as small as it can be. We use the term “native AOT” to describe that point on the AOT spectrum. The single file solution we have in .NET 5.0 doesn’t satisfy this definition of AOT. It’s a big step forward, but it isn’t “native AOT.”

A recent Native AOT community survey, showed us that there’s more of a need to officially support native AOT in .NET. 52% of our survey respondents (n=1,344) told us that they would like to write more projects in .NET (but can’t) or have written .NET projects in a different environment (Rust and Go) because of missing native AOT options.

Summary

This objective describes the continued investment and evolution in the features and integration of single file, trimming, and source generators (to name just a few). Many of these areas are complimentary to each other such that a characteristic of source generators for example is that it can help remove major barriers to linker-based and AOT (ahead-of-time) compilation optimizations.

Many of these areas will require ecosystem and library authors to participate in as well (i.e. trimming) and we will need to build specific tooling to enable these features to be utilized in libraries and will need an outreach program for them as well. We’ve also identified that many of the top NuGet packages people make heavy use of reflection to discover types at runtime. Incorporating these packages is essential for most .NET apps, so the “linkability” and ability for your code to make use of AOT compiler optimizations is greatly affected. We’re looking forward to working with our wonderful OSS community to see how these packages could use source generators and improve the overall .NET ecosystem.

User Stories

Support assembly load context throughout the product #43544 (P2)
Source generators continue to assist with runtime and framework features #43545 (P2)

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[samsp-msft]

Over time, the children of this got moved out, so cleaning out the remainders, and closing.

[danmoseley]

Note that although this is marked Cut, it does not mean actual work is Cut. It's removing dupes - AOT and single file have their own epics now