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.
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?
- 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;
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.