Non-conforming container support in Minimal APIs

dotnetjunkie commented 2 years ago

Is there an existing issue for this?

[X] I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

I've been trying to write documentation on how Simple Injector users can integrate with the new ASP.NET Core Minimal API model, but it seems the injection of services into Minimal API map delegates is tight to the built-in DI abstraction, without the existence of an abstraction of some sort (such as MVC's IControllerActivator) to replace to hook into the pipeline.

The documentation shows the following example where Service is injected into the delegate and resolved from the configuration system:

app.MapGet("/{id}", ([FromRoute] int id,
                     [FromQuery(Name = "p")] int page,
                     [FromServices] Service service,
                     [FromHeader(Name = "Content-Type")] string contentType) 
                     => {});

Context

Simple Injector is a so-called "non-conforming" DI Container, meaning that it doesn't replace the built-in DI Container, but instead lives side-by-side the built-in container. Where the built-in container is used to resolve framework and third-party components, Simple Injector is used by the application developer to resolve their application components. This concept of non-conforming containers should be well-known within Microsoft, for instance from former discussions such as https://github.com/dotnet/aspnetcore/issues/30115, https://github.com/dotnet/aspnetcore/issues/29194, https://github.com/dotnet/aspnetcore/issues/28957, https://github.com/dotnet/aspnetcore/issues/14585, https://github.com/dotnet/aspnetcore/issues/8886 and https://github.com/aspnet/DependencyInjection/issues/334.

Describe the solution you'd like

The introduction of an interception point that would allow non-conforming containers (and other interested parties) to intercept the creation of dependencies that are injected into Minimal API maps.

ghost commented 2 years ago

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

dotnetjunkie commented 2 years ago

I'd like @davidfowl to chime in on this one.

I might be overlooking an existing extension point here that can be used to achieve this. David, do you know of any extensibility point that we can use to achieve this? Your feedback is appreciated.

Cheers

davidfowl commented 2 years ago

Minimal APIs are very efficient in the way code is generated to fill in parameter. There's no abstraction and we basically generate the code you would have hand rolled yourself to bind each of the known parameter types. There are a few paths forward here:

Simple injector would support a new type for binding from it's container. This type would can implement BindAsync on a type and support .e.g:

class FromSimpleInjector<T>
{
  public FromSimpleInjector(T service) => Service = service;
  public T Service { get; }

  // This will get called when the parameter is bound
  public static FromSimpleInjector<T> BindAsync(HttpContext context) => new(context.RequestServices.GetRequiredService<Container>().Resolve<T>());
}

In .NET 7 there's route handler filters and https://github.com/dotnet/aspnetcore/issues/35489 that will make this a little smoother

ghost commented 1 year ago

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

dotnet / aspnetcore