v3.2.3 plan

[omar]

Edit: my original post incorrectly assumed v3.2.3 had a the read only kernel in it. It did not. I've since modified this post.

Hello guys,

I think it's important to continue maintaining v3 of Ninject if the v4 changes are going to contain the immutable kernel changes (ReadOnlyKernel). This breaks a fundamental use case of Ninject where a Kernel can be added to and read from at the same time, see #176.

Many folks (like us) would like to continue using Ninject but migrate to ASP.NET Core (without going to .NET Core). We can continue targeting .NET Framework 4.6 but there's a few fixes in v4 that are not in v3 that are needed to get Ninject working with ASP.NET Core, for example #143.

Once that's complete, I think Ninject users will be in a much better state to migrate to ASP.NET Core and .NET Core. We can then look at supporting netstandard by leveraging the work that @onovotny did on the branches "bait-switch" and "net-standard".

Would love to hear some thoughts on this approach. As it stands, the thought of moving off of Ninject to Autofac, LightInject, or StructureMap seem more compelling given the current state of things.

[BrunoJuchli]

@omar side-question: what's your approximate timelime for a decision to stick with Ninject or move to another container? Or at which point would you need to have a working Ninject "netstandard" to stick with it?

[omar]

We're starting to do the necessary work to migrate our web applications to ASP.NET Core now, so we're feeling the pains already. However, we're not migrating to .NET Core. We'll continue to target .NET 4.6 probably until netstandard2.0 is released and supported by .NET Core.

As it stands, we've had to abstract all the DI logic into a custom/neutral container that then calls into either Ninject's IKernel or the Microsoft.Extensions.DependencyInjection's IServiceCollection depending on the application being bootstrapped. It works but it's less than ideal as that meant we had to touch all of our bindings/modules to use the custom syntax we created.

As a note, my original post was incorrect, version 3.2.3 doesn't have the read only kernel. However, it needs a lot of the fixes that are in 4.0.0 to work with Microsoft's DI framework. I'll correct my OP.

[BrunoJuchli]

@omar so you're current pain is more related to #177 / #201 than actual support for .NET Core?
(I'm sorry, i'm not really up-to-date with asp.net core)

[einari]

We (Bifrost) have a dependency on Ninject and specifically .NET Core/.NET Standard. Any plans on getting a release version of Ninject? We're running into problems with NuGet not wanting to automatically install on Windows in VS2015 because our version is a release version and yours is a pre-release. It kinda makes sense from a semver perspective and not making people dependent on you to actually take a pre-release dependency without being conscious about it.

Interesting enough; the dotnetCLI is not complaining about this.

[scott-xu]

3.3 is on progress.