@jstafford it would seem this sample closely matches your scenario https://docs.particular.net/samples/dependency-injection/aspnetcore/
It does That’s actually where I got the idea to use Autofac as mentioned in my second comment. Seems silly to bring that in for just this purpose, hence the question about whether or not there’s already an NServiceBus container library/extension that solves this directly. I tried implementing my own ContainerDefinition but wasn’t quite working. Some NSB classes weren’t Building correctly.
Interesting perspective. i will point some people with more DI knowledge towards this thread.
Ah @jstafford I get what you are saying. I looked at the problem from the wrong angle. The downsides of the uniform container that we introduced is that as you rightfully stated we require the container implementation to enable injection into handlers. Since we are currently (maybe not yet ) providing a container implementation for the Microsoft.Extensions.DependencyInjection you need another container such as Autofac to bridge between.
I see… Ok I’ll just use the Autofac bridge for now then. Hopefully we’ll see NServiceBus.MicrosoftDI (or whatever) before too long
@jstafford I have created an internal issue to get this done. At this point, I don’t have an ETA for it but can let you know once it gets prioritized.
That’s all I can ask for! Thanks!
Welp… it finally bit me. I’m playing with netcore2.1 release of SignalR and it would seem that the Autofac solution for copying registrations is not fully working. I can see that the IHubContext<T, K> registrations are in IServiceCollection but they’re not being copied over to the Autofac builder. No errors. No clue what’s up. Point is… a first class, supported IServiceCollection implementation would be swell.
Great stuff!. Would you want to add this to our docs site?
If you need help to get it going feel free to ping me at daniel dot marbach at particular dot net
Awesome! I just gave it a try in a test project and things seem to be in working order. Straight into production, what could go wrong amirite?
We already use it in production .
Bangarang. I’m all over this, thank you!
For the reference, we recently added the extension to our docs site
@twenzel ach… ok so this still has the same problem I was having with Autofac in that the services aren’t being updated. For example,
IHubContext<T> which is needed if an NSB handler ever hopes to being to communicate with a user connected to the hub. The problem is that as user connect and disconnect from the hub,
IHubContext gets updated by the framework. It would appear that those changes aren’t being picked up in NSB’s internal service collection, almost as if the service collection is being copied from IServiceCollection instead of adapted, if that makes sense. I haven’t actually looked at the code yet, but this is what I guess is happening.
The result is:
- service starts up
- The current state of
IHubContextis registered with NSB
- A user connects and
IHubContextis updated with that connection info
- A message is received by the NSB handler which requests
- The handler tries to send a message to the connected user but the user’s connection doesn’t exist on this instance of
- The user never receives the message
I believe this is fixable in some way as I was able to find a workaround with the Autofac container by actually replacing the default netcore service provider with Autofac.Extensions.DependencyInjection.ActofacServiceProvider.
I don’t know for sure, but I think what might be happening is that the Autofac extension might be wrapping service definitions in adapters instead of creating new service definitions for NSB so that any changes are made available. So if I’m correct about the implementation, then I think the fix would be to not copy service definitions but create adapters instead.
A bit more info in the issue I opened up a while ago including a repro and the autofac workaround described: https://github.com/aspnet/SignalR/issues/2347
I was able to verify that this is not a problem with SignalR but rather a problem with how libraries are interfacing with NSB’s IoC container. Autofac is an ok workaround at the moment, but I’d REALLY rather not being dealing with THREE different IoC containers, you know?
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
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.
I also don’t want to use Autofac and the workaround to store it in a static variable sounds not very good.
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.