Multiple configurations/multiple middleware instances

[wagich]

In a current project I needed to handle two distinct image sources with different paths/naming conventions and IImageProviders.

It was important they didn't "cross streams", so I thought I'd be nice if I could just stand up two completely different named configs (using named options and maybe the new keyed services feature) and then be able to do something like this to bind a specific config with a specific middleware instance:

services.AddImageSharp()
    .AddProvider<DefaultImageProvider>();

services.AddImageSharp("custom")
    .ClearProviders()
    .AddProvider<CustomImageProvider>();

app.UseImageSharp(); // default config
app.Map("/customProvider", subBuilder => subBuilder.UseImageSharp("custom")); // named config "custom"

For now I'm checking Request.PathBase inside the image provider which seems to work, but looks pretty hacky to me because it couples the provider to the middleware usage/position.

[JimBobSquarePants]

Keyed services IMO is a poorly implemented hack to fix an issue for poorly implemented code. Image providers already work in isolation. The middleware will use whichever one returns match for the path and ignore the rest.

[wagich]

Leaving aside the keyed services 😂, am I reading this correctly as: don't bother with the middleware pipeline and just move everything to the providers?
While this certainly works, it'd be nice to be able to use other middleware functionality (routing for one, but also authentication, authorization etc.) in a more targeted fashion instead of having to re-implement everything inside the provider. It'd also make a provider much more flexible to use.
All that said I completely understand if this is an area you don't want to invest in.