Comments on: Ninject 2 and Extensions

By: Thomas Scheelhardt

Thomas Scheelhardt — Thu, 25 Feb 2010 13:38:28 +0000

And one more of the same… Is Ninject dead and if not is there an expected release data for version 2?

By: Tom R

Tom R — Wed, 09 Dec 2009 16:50:22 +0000

Same question from over here.. Is Ninject dead?

We are just evaluating this framework and really like what we see but are hesitant about picking up a dying technology.. any news?

By: Oliver Weichhold

Oliver Weichhold — Tue, 27 Oct 2009 23:10:34 +0000

5 Months later – same question: Is it dead? :)

By: Nate Kohari

Nate Kohari — Mon, 01 Jun 2009 00:30:36 +0000

@Adriano: Nope, it just hasn’t needed much attention lately. :) Full release will be coming soon.

By: Adriano Machado

Adriano Machado — Sun, 31 May 2009 21:59:30 +0000

Is Ninject 2.0 development dead?

By: Michael Brown

Michael Brown — Fri, 08 May 2009 14:59:09 +0000

Looks like Christoph had the same idea as me kind of.

By: Michael Brown

Michael Brown — Fri, 08 May 2009 14:58:05 +0000

This is just a thought…what if you made the extension loading mechanism an extension itself? And require the user to load it if they want to use it.

By: Christoph Walcher

Christoph Walcher — Tue, 21 Apr 2009 07:23:24 +0000

I like the extension loading idea, but not turned on by default. I’d opt for a solution where an ExtensionDiscovery strategy class is passed to ninject to load extensions.

Possible ExtensionDiscovery strategy implementations could be:
* NoExtensionDiscovery
* AssemblyExtensionDiscovery
* AutoExtensionDiscovery

with NoExtensionDiscovery as default.

IExtensionDiscovery interface would have a method GetExtensionTypes with a signature somehow like this:

IExtension[] GetExtensionTypes()
{
…
}

Code could look like this:

var settings = new NinjectSettings { ExtensionDiscovery = new AssemblyExtensionDiscovery().ByType().ByType() };
var kernel = new StandardKernel(settings, …);

Could be nice, no selector argument needed, extensible as such too.

By: Peter Meyer

Peter Meyer — Thu, 19 Mar 2009 05:12:08 +0000

One things for sure, you won’t be able to please us all! :P

I would vote for a mechanism that is simple and operates in medium trust environments — of course “simple” is subjective to some extent, but medium trust is not.

I don’t think there’s anything wrong with specifying a naming convention for assemblies — and providing the ability to override that pattern in the kernel settings. I think that provides you a mechanism for easy assembly identification and eliminates the need for spinning up a separate app domain. And, yes, it places some responsibility back on the developer to not screw up and RTFM (or wiki page or whatever the case may be), but what’s wrong with that?

By: Brannon

Brannon — Thu, 19 Mar 2009 04:45:51 +0000

Actually, I like the idea of being able to specify a loading strategy. You can include a default strategy that is filesystem-based. The opt-in would be passing an instance of the strategy to the kernel. That would also allow people to create their own strategies if necessary.