Ninject support in ASP.NET MVC 6?

Question

I have been using Ninject very happily for a long time, and I really like it, but before the release of ASP.NET 5 and MVC 6 I came up with a difficult choice.

Basically, outside the gates, Microsoft discovered its own dependency injection system; This is one that, as far as I know, has received a lot of criticism. But my big problem is how it affects other libraries.

From another question that I asked other resources online , it seems that Ninject does not work out of the box with MVC 6. Although there is a “solution” given in the form of the detailed Microsoft.Framework.DependencyInjection.Ninject and Ninject . This is even more complicated because this library requires you to add https://www.myget.org/F/aspnetmaster/ to the NuGet list.

I did some digging and found where this library is; It looks good, it seems that everything is in order, that I can say, but there are a few things that bother me.

• In fact, the library does not seem to be led by the creators of Ninject
• The library is buried quite deep in an obscure repository
• In Ninject's real resources, he never mentions this.

Basically, I am very concerned that this is some kind of gang assistant, and support for Ninject (and even other container libraries) is dying out. Is there any hidden information that I just don’t disclose?

Answer 1

• In fact, the library does not seem to be headed by Ninject

In this library and, it would seem, they also , look that Microsoft created samples of dependency injection providers, which were removed in beta . Note that the link to DI in MVC 6 that your original question refers to says the following;

These DI container adapters are temporary and available for reference; we expect that they will eventually be removed and replaced by their respective container owners.

As it should be. Microsoft should not be held responsible for third-party support.

• The library is buried quite deep in an obscure repository

If you do not know, ASP.NET 5 is still under development. Beta 7 is available on nuget as a preliminary release, but there are other sources, including:

• https://github.com/aspnet/ (source)
• https://www.myget.org/gallery/aspnetvnext (build nuget dev from the above)
• https://www.myget.org/gallery/aspnetmaster (assembling the branches of the nuget editor in chief from the above [same as your question])

These sources are supported by Microsoft.

• In Ninject's real resources, he never mentions this.

As with any new development, third-party library vendors themselves must determine when (if at all) they will implement their products that support the new code base. For some, this will be considered the most effective until the new formation is officially released, since changes to the violation of the API are still very likely until this point. Will support be implemented at all, of course, to the resources of suppliers and / or in the case of the open source community.

Answer 2

There is a discussion among custodians of existing DI libraries about whether to create, maintain, and maintain an adapter for the new ASP.NET embedded DI system. Those supporting Autofac have confirmed that they will create and support the adapter, and the Ninject command was silent and other commands such as the Simple Injector command (including me) explained that they would not support the adapter.

Personally, I believe that the ASP.NET Core DI built-in library is a good and clean DI library, but it is limited to simple applications. As I explained here , many of the features needed to develop supported SOLID-based applications are not supported. However, like the Unity DI library made a couple of years ago, I think this built-in container can make developers start using dependency injection, which is a victory for our industry.

These limitations make the built-in container particularly suitable for customizing and expanding the ASP.NET system itself. To create large supported applications, you will need to use a different DI library. This, of course, is good; You will need to choose the right tools for the job.

Unfortunately, until now, the ASP.NET team has publicly published using a different DI library, meaning you have to write / use an adapter. Unfortunately, this is not a valid IMO message because most DI libraries are not compatible with the API provided by the inline container (as I explained here and here ). Only Autofac seems reasonably synchronized, which explains why the Autofac team prefers to support the adapter. But note that even Autofac turned out to be incompatible with the abstraction that Microsoft defined, and they (like StructureMap) had to make big changes before their product could even match the abstraction. And those supporting Autofac are very upset about the whole process and the abstraction as a whole. And, as I explained here , even the version of ASP.NET implemented by the Ninject adapter is broken.

This message from the ASP.NET team to use the adapter is IMO a big mistake because it will stifle innovation (while the DI library itself is not, it is just another DI library). The ASP.NET team is promoting a model in which both your application components and the ASP.NET system (and all other subsystems that will be connected in the future) will be registered in your user container. It is much wiser and practical to keep your application configuration separate from the ASP.NET system configuration (as described here ).

Because of this, I find using an adapter for any container more useless. As I showed here , it's really easy to plug in your own DI container, leaving it completely separate from ASP.NET registration. This means that you do not need Ninject support to use Ninject effectively in your ASP.NET Core project. The only thing Ninject needs to do is create a version compatible with .NET Core (in case your product should run on this new platform).

So, I'm not sure that the support is "dying out", although some supporting DI (for example, the Simple Injector team and, possibly, Castle Windsor and Ninject) decided not to build, support and support the implementation of the adapter for the ASP.NET core, because it does not needed and is only on the way.

UPDATE November 2016

I have been discussing some of the improvements in ASP.NET Core with Microsoft in order to simplify the plugin for a container that does not have an adapter (look at my sample repository and especially at Startup.cs from the Ninject sample project ), but so far Microsoft seems to be lagging from progress, because (as Fowler claims) their " displacement to appropriate containers [] blurred [their] visions."