Use Orleans and AspNetCore or The Battle for IServiceProvider

[eisendle]

I opened an issue for aspnet/hosting #1349, regarding dependency injection. The gist in this issue shows the problems which arise when AspNetCore is used together withOrleans in terms of ownership of the IServiceProvider.

I have read somewhere that there will be an generic HostBuilder implementation and Orleans will switch to this new nuget package for building the SiloHost. Is this the plan?

If so, I´d like to challenge this decision, because the HostBuilder enforces ownership of the IServiceProvider and when using two frameworks which use HostBuilder (like in my example AspNetCore and Orleans), there is no easy way to use only one IServiceProvider.

As a result it would be difficult to use AspNetCore and Orleans together.

[Vhab]

~~We've run into a similar issue where we needed DI multi-tenancy. In our case it's Service Fabric services which initialize before Orleans does.~~

+1 for considering a use-case where Orleans does not own IServiceProvider. If this already is possible, this probably could be a request for documentation.

edit:

I took another shot at this just now. Turns out this was easier than expected, at least for our use-case. I'll throw this in here as it might help OP.

This is what it took for making Orleans use an Autofac child scope: builder.UseServiceProviderFactory(services => new AutofacServiceProvider(RootContainer.BeginLifetimeScope(b => b.Populate(services))));

builder is a ISiloHostBuilder and RootContainer is an Autofac IContainer.

I hope this is helpful.

[jason-bragg]

First, we're still figuring out how the host builder and container will work in the longer run, so my comments here are mostly my understanding and should not be taken as our official plan or even the current consensus of the team.

Second, to the degree we can, we're not looking to solve these sorts of problems, but rather let this type of battle be fought by the asp.net team, trusting that what they come up with will most likely work for us. We'll only deviate from their patterns when their patterns don't fit or don't work for Orleans.

I have read somewhere that there will be an generic HostBuilder implementation and Orleans will switch to this new nuget package for building the SiloHost. Is this the plan?

Sort of. We don't really -want- to maintain a host builder. Asp.net's current host (and host builder) is web service centric, but they are building a general version. Our current Silo host builder is modeled off of that work and we hope to move to their version entirely once released.

However, a silo isn't really a 'host'. It's a hosted container of grains. While the current silo host combines the configuration and setup of the host and the silo together, and this pattern will likely always be common and supported, there should be a distinction between a silo and a host. For instance, a silo should, imo, be hostable within a web server host (like kestrel), or on a host built to process events (like EventHub's EventProcessorHost).

My suspicion is that we'll need a silo builder (which would not own the container) to configure and construct a hosted silo. The silo builder would be used with the asp.net host builder to create a host with a silo. We'd likely continue to maintain a silo host builder which configured and built a silo and host together as we do today, mainly for the convenience, since this would likely be one of the most common usage patterns, but that logic would just be a façade over the asp.net generic host builder with our silo builder.

I understand the above probably does not directly address your concern regarding the host, but it should regarding the silo. The silo (and silo builder), imo, should not own the container. If the asp.net host owns the container, than the host will own the container when you use the silo builder with the asp.net host, or when our silo host builder is used. If this is not suitable for an application, it will need to work out the container ownership and hosting itself, then use the silo builder to configure a hostable silo.

I do not suspect this will be worked out fully until Orleans 3.0.

[siennathesane]

Now that 3.0 is out, can this be revisited?

[ghost]

We are marking this issue as stale due to the lack of activity in the past six months. If there is no further activity within two weeks, this issue will be closed. You can always create a new issue based on the guidelines provided in our pinned announcement.

[siennathesane]

@ReubenBond is there a plan to revisit this?

[ReubenBond]

@mxplusb what would you like to see happen?

main no longer requires a host builder at all and Orleans doesn't own the IServiceProvider either (you can call IServiceCollection.AddOrleans(Action<ISiloBuilder>) to add Orleans). We haven't ported that to the release branch (3.x) yet and I was not planning to because it would be a breaking change (is it needed?).

You can create multiple host builders in an application if you want, too.

[ghost]

This issue has been marked stale for the past 30 and is being closed due to lack of activity.