Two containers, always resolve ITransactionalSession properly from only one of them

ArveSystad · August 21, 2023, 6:43pm

Long story short, we’re on a huge migration path from MSQM, WCF, ASPNET MVC etc into a more modern setup. On this journey, we have ended up with some hosts running two containers: One for the main container that boots up as a .Net Generic Host, and one that boots up along with an ASPNET Core (2.1) app as a Background Service.

Most stuff works fine, but since ASP.NET Core 2.1 seems to boot up with a separate container, we can’t resolve ITransactionalSession from within a controller context.

Is there some way to properly add ITransactionalSession + all it’s dependencies in the ASP.NET Core container? Ideally I’m looking for some kind of services.AddNServiceBusInternalsToSupportTransactionalSession(), although I do indeed see that our setup is likely quite…an edge case.

Any good way to fix this in a proper, reliable manner without hidden side effects that hits us in the face half a year into production?

MikeMinutillo · August 22, 2023, 1:29am

We don’t provide anything out of the box to do that for you.

My first instinct would be to find a way to collapse the containers so they contain the same set of services. Something like this c# - Multiple hosts with the same DI container - Stack Overflow

I haven’t tested this but it might give you a way forward.

danielmarbach · August 24, 2023, 9:30am

This might be similar to the question that was asked in

github.com/Particular/NServiceBus.Extensions.Hosting

Introduce generics to avoid the need for multiple DI containers

opened 05:33AM - 19 Oct 20 UTC

moanrose

Having spend a few days getting acquainted with your approach to multiple endpoi…nt hosting, I would like to make a suggestion: ## Introduce generics to avoid the need for multiple DI containers: If you constructed an interface representing an "Endpoint-Context" ` IEndpointContext { Func<HostBuilderContext, EndpointConfiguration> endpointConfigurationBuilder; } ` And register the "Endpoint-Context" like this ` .UseNServicebusContext<T>(this IServiceCollection serviceCollection, Func<HostBuilderContext, T> nservicebusContextBuilder) : where T : IEndpointContext ` You could then use the implementing type as a discriminator on your existing DI registrations, and as search criteria for the AssemblyScanner: ` IMessageSession<MyEndpointContext> IHandleMessages<MyEndpointContext> IHostedService<MyEndpointContext> ` This would in my opinion be a far more elegant solution than the "two containers" approach. This would also eliminate the need for the assembly scanner exclude list.

I have spiked an approach at the time that is outlined in

github.com/Particular/NServiceBus.Extensions.Hosting

Introduce generics to avoid the need for multiple DI containers

opened 05:33AM - 19 Oct 20 UTC

moanrose

Having spend a few days getting acquainted with your approach to multiple endpoi…nt hosting, I would like to make a suggestion: ## Introduce generics to avoid the need for multiple DI containers: If you constructed an interface representing an "Endpoint-Context" ` IEndpointContext { Func<HostBuilderContext, EndpointConfiguration> endpointConfigurationBuilder; } ` And register the "Endpoint-Context" like this ` .UseNServicebusContext<T>(this IServiceCollection serviceCollection, Func<HostBuilderContext, T> nservicebusContextBuilder) : where T : IEndpointContext ` You could then use the implementing type as a discriminator on your existing DI registrations, and as search criteria for the AssemblyScanner: ` IMessageSession<MyEndpointContext> IHandleMessages<MyEndpointContext> IHostedService<MyEndpointContext> ` This would in my opinion be a far more elegant solution than the "two containers" approach. This would also eliminate the need for the assembly scanner exclude list.

and here the PR Multi-hosting on the same generic host sharing a container by danielmarbach · Pull Request #4813 · Particular/docs.particular.net · GitHub