NativeAOT in .NET 7

[agocke]

.NET 6 improvements listed here: dotnet/runtimelab#336

We're now planning the following improvements for NativeAOT in the .NET 7 timeframe:

Goals:

For .NET 7 we want to enable NativeAOT for console apps and native library scenarios. Any libraries which are trim/AOT-warning free should be compatible with these form factors.

Pri 0:

• Move the NativeAOT project out of dotnet/runtimelab and into dotnet/runtime
  • Building
  • Test integration
  • Packaging
• Switch to runtime-built NativeAOT packages
• Onboard first-party dotnet console applications using NativeAOT
  • Build crossgen with NativeAOT and trimming #64571
  • dotnet-trace
• Perf:
  • At least as fast as on JSON and Plaintext TechEmpower
  • YARP
    • YARP startup time < 50ms
  • Start tracking build time
• Diagnostics
  • Introduce AOT compatibility annotations
    • - Add RequiresDynamicCodeAttribute #61239
  • Event pipe
  • Explore SOS extension subset
• Reproducible and verifiable NativeAOT builds runtimelab#1632
  • CFG
  • CET (Shadow stack)
• SDK Support
  • MSBuild property for enabling AOT compilation
• Testing
  • Testing for diagnostic compatibility with the linker
  • Libraries unit testing
• Docs
  • Building apps
  • Build libraries

Pri 1:

Pri 1 items moved to the future, out of the .NET 7 milestone: #69739

There also are some non-goals for .NET 7, particularly in applications that are not well-suited to trimming:

• Complex reflection-dependent frameworks, like ASP.NET MVC and WPF
• Apps with plugin models which dynamically load assemblies, like MSBuild
• Mobile, WASM (already provided by Mono)

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.

[davidfowl]

I think we can get really far with ASP.NET if user code isn't trimmed but framework code is.

I don't see EF in scope either. How do people do data things? ADO.NET?

[agocke]

At the moment we're sticking with user code not being trimmed by default.

As for EF, I think it strongly depends on what people use. My impression is that grpc is more important for microservice-type apps, but this really isn't my area of expertise. My hope is we can use apps like YARP to drive some of this investigation.

[hez2010]

I don't see EF in scope either.

I used to build a demo for using EF with NativeAOT, it requires a bit heavy manual written runtime directives but it works without any problem. However, EF can definitely annotated itself for better trimming support and get rid of the need of runtime directives.

See https://github.com/hez2010/EFCore.NativeAOT

[davidfowl]

but this really isn't my area of expertise

Luckily, this is my area of expertise 🙃.

I'd like to manifest a document that describes the patterns that are AOT unfriendly. I've spent quite some time with native AOT and ASP.NET Core and it would be nice to have a doc for library authors that want to enable trimming to better understand the rules of the game

[davidfowl]

@agocke any reason to keep this a package? Why not have it be first class like the other publish experiences?

[snickler]

Awesome! Does this also have a line item for ensuring it works well in regards to modern Desktop application support? This is a huge want for those migrating from UWP and .NET Native.

[agocke]

@davidfowl Thanks for the feedback, much appreciated. So I take it EF is really common? In that case, I think it would be useful to find a representative app to flush out problems. As you know, serializers are probably the most common problem with trimming, so let's see what we can bring into scope.

I'd like to manifest a document that describes the patterns that are AOT unfriendly. I've spent quite some time with native AOT and ASP.NET Core and it would be nice to have a doc for library authors that want to enable trimming to better understand the rules of the game

We've added some documentation for this at https://docs.microsoft.com/en-us/dotnet/core/deploying/trimming/fixing-warnings. Feedback welcome!

Any reason to keep this a package? Why not have it be first class like the other publish experiences?

That's more a technical description in that we need a "package" to ship it in. It seems like we could integrate this with the publish experience, although we might need a workload for additional dependencies. One thing to also keep in mind is that we have a dependency on certain native toolchain pieces as well, like link.exe or an equivalent linker.

[agocke]

@snickler No plans for GUI apps yet. There's been some success experimenting with WinForms -- it's very close to trimmable once ComWrappers is integrated. We'll just need to see how much bandwidth we have for .NET 7 and how difficult it is to make some of these things trimmable/AOT compatible.

[jkotas]

migrating from UWP and .NET Native.

This depends on microsoft/CsWinRT#373