Integration with C#12 "interceptors"

[nblumhardt]

First, I should say that this is intended as a "heads-up", and not a feature request per se (nor something I am prepared to try implementing), although someone might have fun investigating or implementing it. Please feel free to close without comment :-)

Anyway - interesting thing spotted in New C# 12 preview features:

Interceptors

Static dependency graph resolution for dependency injection, where provider.Register() can be intercepted

Since the term "interceptor" is so overloaded, and already has precedent when it comes to IoC, this one's easy to overlook so I thought it'd be worth mentioning here.

An interceptor, in this context, is a compile-time substitution of one method for another at the call site. The mention of static dependency graph resolution is referring to:

builder.RegisterType<MyService>()

at compile-time with a call to an equivalent method:

builder.Register<MyService>(c => new MyService(c.Resolve<IFoo>()))

(It's not possible to directly substitute RegisterType for the real Register as I'm doing here - the substitute method needs to be defined elsewhere using the new language features.).

By making these substitutions, it's no longer necessary for reflection metadata to be preserved for MyService, so the code will work in AoT scenarios where metadata is trimmed/discarded, and potentially run faster.

Seems like a very interesting feature to explore, from Autofac's point of view :-) 👋

[tillig]

Interesting. We'll have to take a look. Thinking out loud, we would need to account for a few different scenarios:

• Multiple constructors: Different constructors might be picked based on the available parameters in the resolution operation.
• The Func<X, Y, B> relationship: Being able to pass parameters not only through .Resolve<T> but also with the generated function relationship.
• required properties: Keeping the list of properties marked required so they can be injected automatically (doesn't require the PropertiesAutowired() opt-in).
• Property injection in general: PropertiesAutowired() would need the list of properties.
• DynamicProxy interceptors: I don't think this would be affected much, but perhaps some of the proxy generation part of things may need the original type's information so it can generate the proxy.
• Assembly scanning: Finding the list of types in a given set of assemblies.
• Generics: Determining compatibility with closed generics, registering/resolving open generics, that sort of thing - need to sometimes walk the inheritance tree back to base classes and such.

It might be interesting to just start with the simplest cases and grow from there. I'm not sure all-or-nothing would be the way to go, it'd be too big of a bite.

Likely this will have to wait until after I've figured out what to do for the new M.E.DI keyed service support.

[tillig]

Here's an interesting blog article that shows how interceptors will work for AOT compilation and minimal APIs. As a byproduct of explaining how that works, it's a pretty good dive into interceptors in general. It's... pretty nuts. Interesting, but really deep. Also sounds like interceptors might be "experimental" for the .NET 8 release. (Which doesn't mean we shouldn't look at it, just that we should expect to give it a little wiggle room and ability to change.)