You must register and enable all of your components in Root of Composition . This is not related to Ninject, and this tip will be used for all DI containers.
The root of the composition is the path to launch the application in which you connect everything together. Usually you add this root composition to your startup project; in your case, your MVC project.
You should not worry about this, because since your MVC assembly itself depends on the details of another assembly, this does not mean that your user interface logic (for example, your controllers) depends on these details. As you know, controllers should just depend on abstractions. Do not confuse your logical architecture (separation of layers) with physical architecture (how code is divided on disk during deployment). The composition root is logically separate from your MVC end project, although it may be located in the same assembly.
The root of the composition is usually the path to the code of your application that runs at runtime, and it should know everything about everyone. In a console application, your launch project will usually be really, really thin and contain not much, but only the root composition. Due to the architecture of ASP.NET applications, this is usually much more difficult to achieve, for example, because the startup project is a web application and contains all types of types (controllers, views, etc.) that need to be eliminated. Because of this, it is quite natural for web applications that Root Composition is integrated into the web project itself. Again, there is nothing to worry about, because the fact itself does not make your code more dense.
Everything becomes different when you have a business layer that is reused by multiple end-applications (for example, the WCF web service and the MVC application). To prevent code duplication, you move the general registrations from the root of the MVC and WCF composition and place it in the special bootstrapper assembly, which is located on top of the business layer (and all layers below). It can be as simple as having a static class with a static method that accepts an existing Kernel instance and does business-related registration (for most DI infrastructures there are functions for this, but in most cases they are useless and a static public method will be very good ) Each root composition can create its own instance of Kernel , make a registration, transfer the instance to the BL loader, make perhaps a few more registrations after that and save the kernel for use by the application.
But even with multiple end applications, they will still contain their own special wiring (since each application is different) and, therefore, have their own tuple.