FeatureRequest: DynamicProxy support

[John0King]

Is your feature request related to a problem? Please describe.
There no good way to register intercepter in asp.net core with asp.net core's DI eg. ServiceCollection.Add{Lifetime}()

Describe the solution you'd like

services.AddScoped<IMyService,MyService>();
services.AddIntercepter<IMyService,MyIntercepter>() //typed intercepter
// short for service.AddSingeltion<IProxy<IMyService>, AutofacProxy<IMyService,MyIntercepter>>();
servcie.AddIntercepter<Object,MyIntercepter> //  intercepter all

and then populate service and intercepters when AutofacServiceProviderFactory build the container

Describe alternatives you've considered

//alternatives 
service.AddIntercepter<IMyService>(b=>{
   b.Named("abc-intercetper")
})

// in behind , that add mutilple `AutofacIntercepterBuilder`  to the servicecollection

Additional context
None

[tillig]

I don't think we're going to add support for Autofac-specific things to the Microsoft.Extensions.DependencyInjection bridge. The only thing this is for is to adapt existing abstractions in M.E.DI to Autofac. If you want to use Autofac-specific features (like DynamicProxy integration, metadata, etc.), that's why the ConfigureContainer method is available in your Startup class - see the documentation for an example.

[John0King]

@tillig

that's why the ConfigureContainer method is available in your Startup class - see the documentation for an example.

does that means that I must put every the DI register in ConfigureContainer instead of ConfigureService if I want to take advantage of dynamic proxy ? because I need .Register<T>().As<IT>.EnableInterfaceInterceptors()

Have your team discuss before about the proxy support and register method ?

I think the register way in this feature request can enable us to intercept every type in the DI , including any type that registerd with services.AddScope<IT,T>() in ConfigureService , and ConfigureContainer can continue to be use for other Autofac specific features

[tillig]

You can use both ConfigureServices and CofigureContainer at the same time. The two work together to create a single container.

But you are right - if you want to enable interceptors on something, you can't register it in ConfigureServices and then just update it in ConfigureContainer - you'd have to move that registration to just be in ConfigureContainer.

The Microsoft DI abstractions aren't really set up internally to allow for adding this kind of thing in. They are set up to be a lowest-common-denominator confirming container registration mechanism. Trying to bolt on container-specific stuff doesn't make sense for two reasons:

1. It would be a lot of work to try to translate all of the Autofac concepts into a whole different registration language just so, in the end, they'll just get translated right back into Autofac. It's the same reason JSON configuration in Autofac is not literally feature-for-feature compatible.
2. It would actually be confusing to some folks who might think this new language, which works on the Microsoft abstractions, only supports Autofac. I can see folks writing their own libraries, trying to stick to only using the Microsoft container, thinking that this adds the functionality to the Microsoft container rather than actually requiring Autofac.

The whole point of the framework adding ConfigureContainer is this exact use case - folks needing container specific stuff mixed in.

If you still aren't convinced... The best I can offer you is that you're absolutely welcome to write this feature yourself and publish/own that library. We absolutely welcome the community to take on integration projects we're not able to support.

However, the Autofac team won't be creating this functionality, and we won't accept a PR to add it and subsequently own it and support it. I'm sorry.