Support for Microsoft.Extensions.DependencyInjection?

jstafford · October 24, 2017, 3:50pm

I apologize if this has already been asked for; I didn’t find an existing thread…

Is there currently a library that will allow me to use Microsoft.Extensions.DependencyInjection (IServiceCollection and IServiceProvider) as a container? In the docs, I see other 3rd party libraries, but not this one. Any help is appreciated, thanks!

I’m currently using the 7.x beta with an aspnetcore app so prelease packages are ok for me

jstafford · October 24, 2017, 7:08pm

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

danielmarbach · October 25, 2017, 7:02am

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

github.com

danielmarbach/service-fabric-webinar/blob/master/stateless-queues/Front_Stateless/NServiceBusServiceCollectionExtensions.cs

using System.Fabric;
using Messages_Stateless;
using Microsoft.Extensions.DependencyInjection;
using NServiceBus;

namespace Front_Stateless
{
    public static class NServiceBusServiceCollectionExtensions
    {
        // TODO: 2.8
        public static void AddNServiceBus(this IServiceCollection services)
        {
            var endpointConfiguration = new EndpointConfiguration("front-stateless");
            endpointConfiguration.SendOnly();
            var transport = endpointConfiguration.UseTransport<RabbitMQTransport>();

            #region Not Important

            endpointConfiguration.UseSerialization<JsonSerializer>();
            endpointConfiguration.EnableInstallers();

This file has been truncated. show original

Integrates NServiceBus and IMessageSession with IServiceCollection.

See also service-fabric-webinar/Front_Stateless.cs at master · danielmarbach/service-fabric-webinar · GitHub

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?

Regards
Daniel

jstafford · October 25, 2017, 5:16pm

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?

SimonCropp · October 25, 2017, 9:15pm

@jstafford it would seem this sample closely matches your scenario ASP.NET Core Dependency Injection Integration • NServiceBus.Extensions.Hosting Samples • Particular Docs

jstafford · October 25, 2017, 9:20pm

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.

SimonCropp · October 25, 2017, 9:34pm

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

danielmarbach · October 26, 2017, 7:13am

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.

jstafford · October 26, 2017, 5:53pm

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

HEskandari · October 31, 2017, 2:04am

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

jstafford · October 31, 2017, 3:53am

That’s all I can ask for! Thanks!

jstafford · June 2, 2018, 11:57pm

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.

twenzel · August 25, 2018, 1:48pm

Please have a look at NServiceBus.MSDependencyInjection.

danielmarbach · August 27, 2018, 6:05am

Hi Toni

Great stuff!. Would you want to add this to our docs site?

github.com

Particular/docs.particular.net/blob/master/README.md

# [ParticularDocs](https://docs.particular.net/)

![VerifyMaster](https://github.com/Particular/docs.particular.net/workflows/VerifyMaster/badge.svg?branch=master) ![BuildProjects](https://github.com/Particular/docs.particular.net/workflows/BuildProjects/badge.svg)

## How to Contribute

Before you start, ensure you have created a [GitHub account](https://github.com/join).

There are two approaches to contributing.

### Via the GitHub Web UI

For simple changes, the GitHub web UI should suffice.

 1. Find the page you want to edit on [ParticularDocs](https://docs.particular.net/).
 1. Click the `Edit Online` button. This will automatically fork the project so you can edit the file.
 1. Make the changes you require. Ensure you verify the changes in the `Preview` tab.
 1. Add a description of the changes.
 1. Click `Propose File Changes`.

This file has been truncated. show original

If you need help to get it going feel free to ping me at daniel dot marbach at particular dot net

Regards
Daniel

jstafford · September 16, 2018, 4:04am

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?

twenzel · September 16, 2018, 6:27am

We already use it in production .

jstafford · September 16, 2018, 7:07pm

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

danielmarbach · September 20, 2018, 6:47am

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

Regards
Daniel

jstafford · October 16, 2018, 6:07pm

@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: IHubContext<THub> "Singleton access" (Dependency Injection) · Issue #2347 · aspnet/SignalR · GitHub

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?

danielmarbach · November 16, 2018, 10:39am

Hi @twenzel, @jstafford, @simoncropp,

Your input would be appreciated

Thanks Daniel