Support for custom Service Provider

[as-ivanov]

Hi!

First of all, thank you for the great framework!

I'm trying to find out if there is any possibility to use a custom ServiceProvider. As far as I see, there is none. However, since my projects are based on Autofac modules, I'd like to have such functionality to avoid registering components twice.
The idea is to have a custom ServiceProvider which will first look for mock in Dictionary as it's implemented now and if no suitable implementation found, will look in Autofac container for a ordinary implementation. In this way, I'd need to manually register only services which I need to mock in a particular test.

Thanks.

[seniorquico]

It's not currently possible. The TestServiceProvider implementation simply looks for requested services in its own internal dictionary.

It sounds like you're proposing a fallback service resolution strategy. I don't think that will work well in all scenarios, and could lead to subtle issues. Take the following example (and assume the service components are singletons):

You'd have to ensure that any service in your Autofac container does not depend on a service that is being mocked by the TestServiceProvider. Otherwise, the grain under test would effectively resolve two different instances of a singleton type (in this example).

What shortcomings are you finding with the TestServiceProvider that Autofac helps solve?

[as-ivanov]

Hello @seniorquico ,

It sounds like you're proposing a fallback service resolution strategy. I don't think that will work
well in all scenarios, and could lead to subtle issues.

Fair enough.

What shortcomings are you finding with the TestServiceProvider that Autofac helps solve?

It's not about Autofac is somehow better than TestServiceProvider. My concern is about not making the same work twice and not duplicating a registration logic.
In my project every assembly exports an Autofac module which is responsible for registration all dependencies exported from that assembly. Any module may register other modules. Wherein an application module is a root module, which pushes a resulting hierarchy to IoC container.
Using this approach all I need to test my application (or any assembly) is to load a particular module to IoC container and let the test environment use this container to resolve dependencies. Replacing as necessary particular services with mocks. Another advantage is that when any service, for instance, requires a new dependency, only containing module has to be changed (not other modules or tests). When as with TestServiceProvider I need either somehow copy final Autofac container to it, or repeat all registration logic in tests which is very undesirable.

Taking into account your fair remark, if I was able to completely replace the TestServiceProvider with Autofac implementation of IServiceProvider (without any fallback resolution strategy), previously substituting required services with mocks in Autofac container, it could solve the problem.

[seniorquico]

I don't see any hard dependency on the TestServiceProvider. It sounds acceptable to open it up to allow registering a custom "conforming container" implementation.

[as-ivanov]

Great. Let me create a pull request soon.