Thread by @davidfowl

We're working on making ASP.NET Core and EntityFramework work with trimming and ahead of time compilation (.NET NativeAOT). One of the big challenges is moving away from dynamic runtime code generation. Let's talk about what that means👇🏾 #dotnet #aspnetcore

Why do we care about trimming and NativeAOT? Faster startup and smaller output. This is useful for reducing the size of your output, which can be impactful for things like smaller container images.

When you type write a minimal API, the framework will look at the method signature you pass and generate the appropriate code to pass the expected parameters and process the response. The two examples below are mostly equivalent.

Today this is done by generating code at runtime since we have features that depend in runtime knowledge in order to generate code. As an example, when you have a registered service in the DI container then we can detect that and generate service resolution code.

Pivoting away from runtime code generation for a minute, C# has source generators, which allows anyone to write a library that analyses code statically and generate more code. In theory it should be possible to use this to replace some pieces of runtime code generation.

Source generators work well today when there is a natural declaration site. What do I mean by that? Well look at the hello world for source generators:

There's a partial method that is "filled in" with generated code. That pattern works really well when there's a natural place to declare a method or class, otherwise, it tends to lead a slightly awkward user experience. devblogs.microsoft.com/dotnet/regular…

For minimal APIs, we want to generate code based on the user typed and then somehow, use that code at runtime. The user didn't need to write any partial classes or methods, they just turned on the source generator and got this for free. Can we have our cake and eat it too?

We have to solve 2 problems:
1. We need to generate code based on each unique call to MapGet/Put/Post/etc method and we need to be able to identify this generated code at runtime.

2. We need to somehow tell the Map* to use this generated code instead of the runtime code gen.

What cache key can we use to uniquely identify a call to Map? Maybe the method name "MapGet" and the route? That would mean that we can statically determine the entire route at compile time, possible but there are problems when you introduce things like route groups.

Remember we need something that we can determine at compile time that can be retrieved at runtime. What about the file name and line number? It's not perfect but it works well. While running the source generator, we can generate code based on the line and file path.

At runtime you can use the [CallerLineNumber] and [CallerFilePath] attributes to get this data in any method learn.microsoft.com/en-us/dotnet/a…. What happens if you have 2 methods on the same line?

OK we solved the first problem, now what about the second one? How do we trick the compiler into calling our method instead of the one the user originally generated? By generating more specific method overloads!

ASP.NET Core has overloads for app.Map{Verb} that are weakly typed. We can generate overloads that take a strongly typed delegate that will "win" overload resolution and let us wire up the source generated code.

And here's the prototype:
Original code - github.com/davidfowl/uCon…
Generated code - github.com/davidfowl/uCon…

I showed this to @jaredpar today and got this look:

This is one of my finest hacks yet: