Source Generation support for Extensions.DependencyInjection

[jbudbo]

I've tried to take a few deep dives into the way Dependency Injection works through Service Provider and Descriptor and things. From what I can tell, when the time comes to prepare dependencies for a service, the Activator is used and relies heavily on dynamically accessed members. It would be amazing if we could utilize [a] source generator[s] to circumvent using reflection and the Activator to construct our service implementations. For my use case I would think that'd help with cold start situations in my azure services but what I'd really be after is better AOT support when using the baked in DI capabilities. My added hope would be that it could help with creating somewhat cleaner bootstrap code in a given Program.cs (especially for minimal apps) as the generator could also produce a tailor made AddServices method which includes all decorated implementations.

[andrewjsaid]

I was looking at the code and thought of something similar. Essentially there could be an attribute InjectedAttribute which could indicate that a source generator should output a Func<ServiceProviderEngineScope, object?> somewhere discoverable.

The service type could then be tested for the attribute during service registration. On resolving, if the type has the InjectedAttribute generated already then we can use that instead of CallSiteRuntimeResolver. This will speed up both AOT which can't generate code but also in the "regular" .NET since we can avoid calls to ThreadPool.UnsafeQueueUserWorkItem during DynamicServiceProviderEngine leading to a faster startup.

N.B. The place this suggestion falls apart is that a lot of the code generated must reference internal classes such as ServiceCallSite.

Edit: On second review I'm not sure that this is feasible since a lot of the work is done at runtime such that the compiler doesn't know for example which constructor to call. The runtime code generation does indeed take advantage of runtime knowledge i.e. it's not a pure function of the type.

[davidfowl]

See #82679

[BreyerW]

Note situation changed a bit now that UnsafeAccessor will be nearly complete in NET 9. The only scenario missing are internal static classes that are nested in private classes and other similarly obscure scenarios. Im mostly referring to @pakrym comment where he said that MEDI doesnt have limitations with internal stuff and UnsafeAccessor should bridge this gap for source gen

[davidfowl]

I’d ask again, what problem are you trying to solve? Source generation is a solution not a problem.

[jbudbo]

Obviously not speaking for @BreyerW but at least my primary goals from the outset were to explore ways to provide compile time service implementation decision making for dependency injection. Ideally to improve app start times and maybe even runtime performance (though likely this would be more of a micro-optimization). It could even start to drive the Minimal API concept as with SG in place, apps could change things such as:

var builder = Host.CreateApplicationBuilder(args);
builder.Services.AddSingleton<IMyService, InMemoryMyService>();

var app = builder.Build();
... some middleware
app.Run();

to a new method:

var builder = Host.CreateGeneratedBuilder(args);
...
internal CreateGeneratedBuilder(ReadOnlySpan<string> args) {
  ILogger<InMemoryMyService> logger = LoggerFactory.GetLogger<InMemoryMyService>();
  global::SingletonInstanceProvider.AddFor<IMyService>(new InMemoryMyService(logger));
}

or something like that.
My other hope would be that if a service is unknown to DI, then the developer would stand a chance of knowing at compile time rather than through exceptions as runtime startup

[davidfowl]

If the goal is itself source generation the MEDI (Microsoft.Extensions.DependencyInjection) isn't the right tech to use. The registration model is incompatible with generating code at compile time. There are more options (like using interceptors) to do more creative things, but the model is not statically analyzable (registrations come from both library code and source code). It's like trying to statically analyze the values in a List<T>.

I'd suggest looking at some of these #82679 (comment) other options.