Support injecting IEnumerable<T>

[barbosatek]

While other frameworks support resolving this (including the new ASP.net Core DI), ninject doesn't. Would be cool to add this feature so it's easy to replace ASP.net Core DI with ninject.

[BrunoJuchli]

@barbosatek
I believe you are mistaken. It is supported by Ninject.
I know I have used it plenty of times.
@scott-xu or has it been removed?

Also see: #128

btw.: I still don't agree with @idavis and especially not @danielmarbach comments (which I claim to be plain wrong).
Nonetheless:

• Materializing IEnumerable<T> before injection prevents bugs.
• Using Lazy<IEnumerable<T>> for lazy-use cases is concise and works as expected.

[danielmarbach]

@BrunoJuchli I'm glad that my comments are plain wrong ;)

Look at the links you provided. The sole purpose of IEnumerable is to expose a GetEnumerator method. Only when the enumerator is accessed by design the enumeration and thus first materialization should happen. Yes correct my argument is coming from LINQ and its design philosophies that's correct. But if you look at the larger .NET ecosystem and what the history and introduction of LINQ taught us is that enumerables cannot be assumed materialized thus it is a perfectly valid implemenation that ninject decided not to.

Btw. I don't think I've claimed in the original issue that I'm against changing it. Since your arguments about the danger of it are perfectly valid and sound. My whole arguments were around the semantics of enumerable.

Thus if your intention of claiming that I'm wrong is to push forward why this should be changed I think you missed the point since like I said I was never against your arguments. When you look at an OSS framework like Ninject the larger context has to be taken account. When a library has a certain behavior people start building all sorts of assumptions around a certain behavior. If you suddenly redefine a previous behavior you'd better be sure you are not destroying someone else's assumptions. If I understood correctly these were the arguments of @idavis saying if you do not want lazy evaluation use the other support interfaces.

[barbosatek]

@BrunoJuchli
I guess a piece of code explains more than a simple paragraph. Here's an example...

With Microsoft's new Net Core DI framework, you can do something like this:

      services.Add(new ServiceDescriptor(typeof(IDependency), typeof(Dependency1), ServiceLifetime.Singleton));
      services.Add(new ServiceDescriptor(typeof(IDependency), typeof(Dependency2), ServiceLifetime.Singleton));
      services.Add(new ServiceDescriptor(typeof(IDependency), typeof(Dependency3), ServiceLifetime.Singleton));

      ServiceProvider netCoreServiceProvider = services.BuildServiceProvider();
      IEnumerable<IDependency> test1 = netCoreServiceProvider.GetServices<IDependency>();
      IEnumerable<object> test2 = netCoreServiceProvider.GetServices(typeof(IDependency));

and it works as expected, the framework finds all the bindings to IDependency and returns the IEnumerable<IDependency>

With Ninject though, the following example throws an exception (details below).

      kernelConfiguration.Bind<IDependency>().To<Dependency1>();
      kernelConfiguration.Bind<IDependency>().To<Dependency2>();
      kernelConfiguration.Bind<IDependency>().To<Dependency3>();
      IReadOnlyKernel ninjectServiceProvider = kernelConfiguration.BuildReadonlyKernel();
      IEnumerable<IDependency> test3 = ninjectServiceProvider.GetServices<IDependency>(); // THROWS
      IEnumerable<object> test4 = ninjectServiceProvider.GetServices(typeof(IDependency)); // ALSO THROWS

Exception:

Ninject.ActivationException: 'Error activating IEnumerable{IDependency}
No matching bindings are available, and the type is not self-bindable.
Activation path:
  1) Request for IEnumerable{IDependency}

Suggestions:
  1) Ensure that you have defined a binding for IEnumerable{IDependency}.
  2) If the binding was defined in a module, ensure that the module has been loaded into the kernel.
  3) Ensure you have not accidentally created more than one kernel.
  4) If you are using constructor arguments, ensure that the parameter name matches the constructors parameter name.

[BrunoJuchli]

@barbosatek

ok so that's a specific ASP.net Core feature that might not work/no be implemented.
seems like you're using 4.0.0-beta, right?
If that's the case, do you mind trying out 3.3.0? It's the latest stable release and it supports .net standard and it's newer than 4.0.0-beta.

I don't know how ninjectServiceProvider.GetServices works internally, however, with ninject 3.x the following does work:

Bind<IFoo>().To<Foo1>();
Bind<IFoo>().To<Foo2>();

public class Bar
{
   public Bar(IEnumerable<IFoo> foos) {} // will inject 2 foos
 }

---

If it currently does not work for Asp.net core because of lacking infrastructure or because this is not implemented in 4.0, i suggest updating/editing your issue to explicitly specify this.

[barbosatek]

So, it works when the IEnumerable<T> is a dependency, but not when you explicitly ask the IServiceProvider for it, which I speculate is what .Net Core is doing. i.e.

  public class AwesomeTarget : IAwesomeTarget
  {
    private readonly IEnumerable<IDependency> _dependencies;

    public AwesomeTarget(IEnumerable<IDependency> dependencies)
    {
      _dependencies = dependencies;
    }
  }

      var bar = ninjectServiceProvider.GetService<IEnumerable<IDependency>>(); // THROWS
      var foo = ninjectServiceProvider.GetService<IAwesomeTarget>(); // WORKS
      var foo2= ninjectServiceProvider.GetServices<IDependency>(); // THROWS

EDIT

I don't like to speculate, so I went deeper to find where exactly the ASP.Net pipeline calls it
https://github.com/aspnet/Hosting/blob/253be73b6fbc4a23b52080bd5e9d5161eb6cfe37/src/Microsoft.AspNetCore.Hosting/Internal/WebHost.cs#L188