Multiple Ninject Modules giving odd behaviour

Question

This one is a little complex but reproducible in my environment. Architecture as follows;

BindingsLayer
    +-NinjectBindingsModule
    +-NinjectWebBindingsModule

ContractsLayer
    +- ISomeService
    +- IAnotherService

DomainLayer
    +- SomeService : ISomeService
    +- AnotherService : IAnotherService
       {
           public AnotherService(ISomeService) {}
       }

PersistenceLayer
    +- PBADBEntities (Entity framework context)

WebProjectA
    +- Uses bindings in NinjectWebBindingsModule

ConsoleProjectB
    +- Uses bindings in NinjectBindingsModule

Ninject module implementation

class NinjectBindingsModule : NinjectModule
{
    public override void Load()
    {
            Bind<PBADBEntities>().ToSelf();
            Kernel.Bind(s => s.FromAssembliesMatching("MySolution.*.dll")
                              .SelectAllClasses()
                              .BindDefaultInterfaces()
                       );
    }
}

class NinjectWebBindingsModule : NinjectModule
{
    public override void Load()
    {
            Bind<PBADBEntities>().ToSelf();
            Kernel.Bind(s => s.FromAssembliesMatching("MySolution.*.dll")
                              .SelectAllClasses()
                              .BindDefaultInterfaces()
                              .InRequestScope()
                       );
    }
}

Now, the above breaks for me if I run the web project with the following error;

Error activating ISomeService. No matching bindings are available, and the type is not self-bindable.

However, if I change the bindings in NinjectBindingsModule (for the console application, not the web project which is being run), to the following;

class NinjectBindingsModule : NinjectModule
{
    public override void Load()
    {
            Bind<PBADBEntities>().ToSelf();
            Bind<ISomeService>().To<SomeService>();
            Bind<IAnotherService>().To<AnotherService>();
    }
}

Then the web project works correctly. There is no explicit reference to the NinjectBindingsModule class from the web project and neither does any breakpoint get hit if I put one in there. A breakpoint will get hit if I put it in NinjectWebBindings and continue on normally.

This would imply that Ninject is loading up or otherwise scanning all modules in referenced assemblies and doing something with them in regard to binding. Any ideas on how to resolve this without having a separate project per module?

@BatteryBackupUnit, via the auto-created App_Start\NinjectWebCommon.cs file. The kernel is instantiated like; `var kernel = new StandardKernel(new NinjectWebBindingsModule());` — DiskJunky, Sep 08 '15 at 11:25
Can you please re-verify that `NinjectBindingsModule.Load` is not executed? Because on first sight it seems impossible it isn't executed. From what you say it should not be executed though. So the stacktrace when in `NinjectBindingsModule.Load` would be interesting. — BatteryBackupUnit, Sep 08 '15 at 11:36
@BatteryBackupUnit, agreed on all points. I've put a breakpoint in the first line of `NinjectBindingsModule.Load()` and it never gets hit. Same breakpoint in `NinjectWebBindingsModule.Load()` gets hit. I've triple-checked by doing a Find All to see where `NinjectBindingsModule` is used anywhere in the solution and it's used only in the Bindings layer and the Console application. It's a weird one. — DiskJunky, Sep 08 '15 at 11:42
@BatteryBackupUnit, my best guess is that the Ninject.Extensions.Conventions library scans the assembly it's in and does something with all modules but why is a mystery — DiskJunky, Sep 08 '15 at 11:43
no the conventions are not doing that. If you're unable to find the issue through debugging then you'll need to provide a [MCVE](http://stackoverflow.com/help/mcve). In this case probably the best form would be a github repo because it's too much code etc. to put it all into the question. — BatteryBackupUnit, Sep 08 '15 at 12:18
@BatteryBackupUnit, probably best. I'll put one together when I get a chance — DiskJunky, Sep 08 '15 at 13:06

score 0 · Accepted Answer · answered Sep 14 '17 at 20:45

This post is an old one but I thought I'd post the answer here. The issue turned out to be a bug in Ninject that was later fixed as of version 3.2.1. Using the architecture above for other solutions with later versions worked just fine and issue disappeared. In a nutshell, upgrade Ninject if you can.

Multiple Ninject Modules giving odd behaviour

1 Answers1