Continued Ninject support in ASP.NET Core MVC?

Question

I have been very happily using Ninject for a long time now, and I really like it, but I am faced with a difficult choice since the release of ASP.NET Core and MVC Core.

Basically, out of the gate, Microsoft has revealed their own dependency injection system; Which is one that to my knowledge has gotten a lot of criticism. But my bigger problem lies with how it affects other libraries.

From another question I asked and other resources online, it seems that Ninject does not work out of the box with MVC Core. Though there is a "solution" given in the form of a verbose library Microsoft.Framework.DependencyInjection.Ninject and Ninject. This is even trickier because that library requires adding https://www.myget.org/F/aspnetmaster/ to your list of NuGet feeds.

I have done some digging and found where this library is hosted; It looks fine, it seems to work okay from what I can tell, but there are a few things that trouble me.

• The library does not really appear to be headed by the Ninject creators
• The library is buried pretty deep in an obscure repository
• The actual Ninject resources online never mention it

So basically, I am very concerned that this is some kind of band-aide, and that support for Ninject (and even other container libraries) is dying out. Is there some hidden information that I'm just not discovering?

Ordinate

Answer 1

• The library does not really appear to be headed by the Ninject creators

That library, and it would seem these also, look to be Microsoft created samples of Dependency Injection providers that were removed in beta7. Note that the link to DI in MVC 6 referenced by your original question says the following;

These DI container adaptors are temporary and are there for reference; we expect that they will eventually be removed and replaced by the respective container owners.

As they should be. Microsoft should not be responsible for maintaining 3rd party providers.

• The library is buried pretty deep in an obscure repository

If you are not aware, ASP.NET 5 is still in development. Beta 7 is available on nuget as a pre-release, but there are other sources as well including;

• https://github.com/aspnet/ (source code)
• https://www.myget.org/gallery/aspnetvnext (nuget dev branch builds of the above)
• https://www.myget.org/gallery/aspnetmaster (nuget master branch builds of the above [same as your question])

These sources are maintained by Microsoft.

• The actual Ninject resources online never mention it

As with any new development, 3rd party library providers must themselves determine when (if at all) they will provide implementations of their products that support the new codebase. For some, it will be seen as most efficient to wait until the new framework is officially released, as API breaking changes are still highly likely to occur until that point. Whether support will be implemented at all is of course up to the providers resources, and/or in the case of open source the community.

Vulvitis

Answer 2

There is a discussion going on between maintainers of the existing DI libraries, whether or not to build, maintain and support an adapter for the new ASP.NET built-in DI system. The Autofac maintainers have confirmed that they will create and support an adapter, while the Ninject team has been silent, and other teams such as the Simple Injector team (that includes me) have explained that they won't support an adapter.

Personally, I think that the ASP.NET Core built-in DI library is a nice and clean DI library, but it is limited to simple applications. As I explained here, many features that are required for developing maintainable applications built around the SOLID principles are not supported. However, just like the Unity DI library did a couple of years ago, I think that this built-in container might actually trigger developers to start using dependency injection, which is a win for our industry.

These limitations make the built-in container especially suited to configure and extend the ASP.NET system itself. To build large maintainable applications, you will need to use a different DI library. This of course is fine; you will have to pick the right tools for the job.

Unfortunately, up until now, the ASP.NET team has communicated publicly that using a different DI library, means you will have to write/use an adapter. This unfortunately is the wrong message IMO, because most DI libraries are incompatible with the API presented by the built-in container (as I explained here and here in detail). Only Autofac seems reasonably in sync, which explains why the Autofac team choose to maintain an adapter. But do note that even Autofac has proven to be incompatible with the abstraction that Microsoft defined, and they (just like StructureMap) had to make big changes to their product to even be able to comply with the abstraction. And the Autofac maintainers are severely frustrated about the whole process and the abstraction in general. And as I explained here, even the ASP.NET provided adapter implementation of Ninject is broken.

This message by the ASP.NET team to use an adapter is IMO a big error, because this stifles innovation (while the DI library itself doesn't; it's just another DI library). The ASP.NET team is promoting a model where both your application components and the ASP.NET system (and all other sub systems that will plugin in the future) will be registered in your custom container. It is much more reasonable and practical to keep your application configuration separate from the configuration of the ASP.NET system (as explained here).

Because of this, I find the use of an adapter for any container rather useless. As I shown here it is really easy to plugin your own DI container, while keeping it completely separate from ASP.NET's registrations. This means that you don't need support for Ninject to be able to effectively use Ninject on an ASP.NET Core project. The only thing Ninject needs to do is to create a version that is compatible with .NET Core (in case your product needs to run on that new platform).

UPDATE: "Ninject 3.3.0 was released September 26th 2017 and now targets .NET Standard 2.0 and thus also runs on .NET Core 2.0." source

So in a nutshell, I'm not sure that support 'is dying out', although some DI maintainers (such as the Simple Injector team, and probably Castle Windsor and Ninject as well) have chosen not to build, maintain and support an adapter implementation for ASP.NET Core, because it is not needed, and is only in the way.

UPDATE November 2016

I've been discussing some improvements to ASP.NET Core with Microsoft to make it easier to plugin a container that don't have an adapter (take a look at my example repository and especially to the Startup.cs of the Ninject sample project), but until now Microsoft seems to stall progress because (as Fowler states hisself) their "bias towards conforming containers [is] clouding [their] vision".

Revivalism

Thanks for the insightful post, the major thing missing from the built in DI container is there is no convention based mapping. I HAVE to include every single project under to my startup project and map the dependencies. This seems like a huge misstep unless I'm missing something. – Isabeau

@Isabeau The built-in container is especially meant as a configuration system for ASP.NET itself. So this means that you can easily swap parts of ASP.NET and 3rd party components can use the same configuration model. The built-in container is built around that model, and that explains why some features are not inplemented. Note that batch-registration is really easy to write yourself on top of the container, and to become a compelling DI library other more important features should be implemented first. But again, don't abuse the DI system for registering your own types. – Revivalism

Gotcha that makes sense. – Isabeau

So, the first release v1.0 of ASP.NET Core is out, support still lacks? Any news from container providers, will they create a compatible version soon. I am interested especially in Unity, as I am used to this DI container... – Blastogenesis

I created demo project ninject + asp.net core github.com/hodzanassredin/core-angular – Hassi

Keep fighting the good fight @Steven. I appreciate the effort you're putting into this and I agree that containers shouldn't have to adapt to the framework's built-in DI. Thanks for the Ninject code sample, it will make our migration to ASP.NET core easier. – Perineurium