Support for Microsoft.Extensions.DependencyInjection?


(Jeremy) #2

In the meanwhile, I seem to have been able to use Autofac as a bridge between NSB and IServiceCollection

(Daniel Marbach) #3

Hi Jeremy

Not sure I entirely follow. It is possible to use IServiceCollection natively with NServiceBus. You don’t even need an external container. For example

Integrates NServiceBus and IMessageSession with IServiceCollection.

See also

We never specify a specific container. And the example showed above uses NSB v6. Did you have anything specific in mind that is not supported as of now?


(Jeremy) #4

So, if I don’t specify a container, it seems that the message handlers don’t get injected with any services. The example only shows you accessing the service collection, and the full example shows registering IMessageSession with the service collection which I think is another matter. I’ve otherwise set my NSB installer up the exact same way. NSB doesn’t appear to be using IServiceProvider to inject any of the handlers (IHandleMessage). Is there something else I’m missing?

(Simon Cropp) #5

@jstafford it would seem this sample closely matches your scenario

(Jeremy) #6

It does :slight_smile: 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.

(Simon Cropp) #7

Interesting perspective. i will point some people with more DI knowledge towards this thread.

(Daniel Marbach) #8

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 :wink: ) providing a container implementation for the Microsoft.Extensions.DependencyInjection you need another container such as Autofac to bridge between.

(Jeremy) #9

I see… Ok I’ll just use the Autofac bridge for now then. Hopefully we’ll see NServiceBus.MicrosoftDI (or whatever) before too long :slight_smile:

(Hadi Eskandari) #10

@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.

(Jeremy) #11

That’s all I can ask for! Thanks!

(Jeremy) #12

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.

(Toni Wenzel) #13

Please have a look at NServiceBus.MSDependencyInjection.

(Daniel Marbach) #14

Hi Toni

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


(Jeremy) #15

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? :smiley:

(Toni Wenzel) #16

We already use it in production :wink:.

(Jeremy) #17

Bangarang. I’m all over this, thank you!

(Daniel Marbach) #18

For the reference, we recently added the extension to our docs site


(Jeremy) #19

@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, services.AddSignalR registers 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 IHubContext is registered with NSB
  • A user connects and IHubContext is updated with that connection info
  • A message is received by the NSB handler which requests IHubContext
  • The handler tries to send a message to the connected user but the user’s connection doesn’t exist on this instance of IHubContext
  • 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:

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?

(Daniel Marbach) #20

Hi @twenzel, @jstafford, @simoncropp,

Your input would be appreciated

Thanks Daniel

(Nathan Arnott) #21

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.