Circular reference in IServiceProvider when using Autofac DI

[Maarten88]

I upgraded to Orleans 1.4.0, and got an error from Autofac, which I use as my DI framework with Orleans instead of the default Microsoft DI. When starting the Silo host, Autofac complains:

Circular component dependency detected: Orleans.GrainFactory -> System.IServiceProvider -> System.IServiceProvider.

And then the silo refuses to start. It seems Microsoft DI is more forgiving, returning services.BuildServiceProvider() instead of AutofacServiceProvider(builder.Build()) with the exact same registrations results in a succesful start of the silo.

Runtime/OutsideRuntimeClient.cs line 110 reads:

services.AddSingleton(sp => sp);

My guess is that Autofac does not like that, it seems circular indeed so I guess this causes the bug. I'm not sure why that line is there; it seems it can be safely deleted?

[ReubenBond]

Hi @Maarten88, thanks for reporting the issue. The reason that the container registers the service provider itself is so that it can expose the service provider to other components.

I'm not sure what the best way to fix this is and have it work on all containers - do you know?

[Maarten88]

@ReubenBond I think exposing the serviceprovider is built-in, no registration is needed.

I tried this by removing the IServiceProvider service registration (which is the first one) before building the provider in my Startup:

services.RemoveAt(0);
return services.BuildServiceProvider();

And then asking for the IServiceProvider in an dependency in a grain constructor. The provider is injected correctly.

So I think the DI frameworks (both Microsoft and Autofac) have this built-in.

[ReubenBond]

Oh good, would you be able to submit a PR to make that change in OutsideRuntimeClient and Silo?

[jdom]

Thanks for reporting and the PR, @Maarten88. I verified that we can still successfully resolve IServiceProvider even when using the built-in container. I'll add a note to the known issues section so people know how to workaround it until 1.4.1 is released.

BTW, we should create a test project adding some coverage for 3rd party containers, so that we avoid regressions such as these.

[jdom]

This was fixed in the 1.4.1 release, so if you were doing the workaround to remove the first item from the service collection, please remove that workaround, or you might end up removing a different service registration