Thoughts on the idea of replacing NServiceBus container abstraction with Microsoft DependencyInjection Abstraction?

Announcements
1

Hi everyone,

NServiceBus currently provides its own IoC container abstraction that supports a variety of containers, such as Autofac, CastleWindsor, Ninject, SimpleInjector, StructureMap, and many more. We’ve been seeing an increasing interest in and usage of Microsoft.Extensions.DependencyInjection, so we did a feasibility study to see if it would be possible to deprecate the NServiceBus conforming container and replace it with the Microsoft.Extensions.DependencyInjection.Abstractions type widely known as IServiceCollection.

By doing so, NServiceBus would be compatible with all containers that support IServiceCollection, and there would be no more need for us or the community to write container adapters for NServiceBus. From an educational standpoint, as a team lead or developer, you would no longer need to understand and explain the NServiceBus dependency lifecycle. Once you understand the Microsoft abstraction, the integration with NServiceBus would be seamless. Other scenarios, such as when NServiceBus is hosted inside ASP.NET Core using IServiceCollection, would also benefit from the easier sharing of common registrations for the container.

There are some drawbacks that come with making this change. We would have to upgrade the minimum required .NET Framework version to 4.6.1, and we could no longer mark the NServiceBus assemblies as CLS compliant, although the code could still be compliant. Another side effect would be that we’d have to deprecate the Spring container adapter since there is no official IServiceCollection support.

The Microsoft Dependency Injection scopes map well to the NServiceBus container abstraction. Users transitioning to using the Microsoft scopes will be guided through deprecation messages in code as well as extensive upgrade guides on our documentation site.

  • What do you think about the plan of replacing the NServiceBus container abstraction with IServiceCollection?
  • Do you see benefits to moving to IServiceCollection in your projects?
  • Do you see your projects switching to IServiceCollection in favor of the DI container you are currently using?

Your input is much appreciated.

Regards
Daniel

2 Likes
2

Hi Daniel,

I would love to see this improvement! The requirement for adapters does feel not correct.
So building your DI upon IServiceCollection would be feel like more natural.

I guess there would be also some performance improvements when using the native DI container directly.

So in total, yes please do it! :wink:

1 Like
3

For any project using ASP.NET Core, we try to stick with the built-in DI as long as possible. It only has a few missing features that we run into frequently, but nothing major enough that would force us to try to adopt another container.

At this point, we only use 3rd-party containers when something about our hosted application forces us to. This is now WPF and NServiceBus applications.

4

At this point, we only use 3rd-party containers when something about our hosted application forces us to. This is now WPF and NServiceBus applications.

Haven’t try yet but, can’t regular NSB endpoints be hosted using the new .NET Generic Host?

5

Yep, they can. NSB though has its own container, so to simplify things we’d pick the same container across the board.

6

Hi @danielmarbach ,

Is there any update on this topic?

Regards,
Dogan

7

It’s a work in progress that will be fully enabled by the upcoming 7.2 release. Here is the documentation about externally managed containers and a sample showing how to use it with ASP.Net Core.

.m

8

@doganak

it has been released

Hope that helps
Regards
Daniel

9

NServiceBus.Extentions.Hosting 1.0.0 is released. Please see announcement post.