You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Morten thanks for your feedback and brainstorming solutions.
The problem and solution you are describing is mostly relevant for people that need to share a common container between the multiple instances. Can you elaborate a bit more on your needs why you need to share a container and thus instances managed by that container? What kind of scenario are you solving?
FYI I've spiked the approach to share a container here
That being said keep the feedback coming because we want to understand the scenarios and needs of our customers better so that we can create better guidance and potentially even more integration libraries where necessary.
Having spend a few days getting acquainted with your approach to multiple endpoint 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.
The text was updated successfully, but these errors were encountered: