Any headway on this? We are also stuck with the SignalR issue and how NSB is copying (instead of adapting) services from the IServiceProvider. Our workaround right now is to place all needed HubContext instances in global static variables instead of using IoC in the NSB handlers. Very bad practice, but don’t have another solution. We do not want to introduce AutoFac as a bridge.
I’d really love to see first-class support for this. The new Azure AppService WebJobs 3.0 uses MsExtDI out-of-the-box as well as HostBuilder
2 Likes
Hi, I have the same problems while testing with SignalR in a Handler. In an Controller it works fine and the IHubContext has connections.
In a handler the IHubContext has no connections and we can’t send something to the Clients.
It is the same behavior like described from @jstafford and @NArnott.
I also don’t want to use Autofac and the workaround to store it in a static variable sounds not very good.
kind regards
I’ve finally found some time to investigate the issue with SignalR and the Microsoft Dependency Injection integration for NServiceBus. The root cause of the issue is how the integration works, it ends up creating a separate container instance that is not shared with ASP.Net Core runtime, causing components resolution to misbehave.
I have a very raw fix for it, I raised a draft PR to discuss with maintainers how to proceed.
Thanks to @twenzel NServiceBus.MSDependencyInjection 0.1.4 is now available on nuget: NuGet Gallery | NServiceBus.MSDependencyInjection 0.1.4
The PR I raised had been merged and it’s now possible to configure an ASP.Net Core project like in the following snippet:
public IServiceProvider ConfigureServices(IServiceCollection services)
{
services.AddSignalR();
services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
IEndpointInstance endpointInstance = null;
services.AddSingleton<IMessageSession>(_ => endpointInstance);
var ec = new EndpointConfiguration("some-endpoint-name");
ec.UseTransport<ATransport>();
UpdateableServiceProvider container = null;
ec.UseContainer<ServicesBuilder>(c =>
{
c.ExistingServices(services);
c.ServiceProviderFactory(sc =>
{
container = new UpdateableServiceProvider(sc);
return container;
});
});
endpointInstance = Endpoint.Start(ec).GetAwaiter().GetResult();
return container;
}
Using the above approach the result is that the ASP.Net Core application and the NServiceBus endpoint will effectively share the same container, making sure both can resolve and share the same components.