The conventions extension has been completely rewritten with a new API for Ninject 3.0. This article references the 2.X releases.
Conventions binding is implemented through extension methods on the IKernel interface. In order to use these extensions, first download or compile a release of the Ninject.Extensions.Conventions project. Once the library is referenced, type:
into the source file you are using to configure your Ninject kernel. This will add two additional methods to the IKernel interface:
You can either construct and make calls on an AssemblyScanner, or you can pass a function/lambda expression that will run the same operations. This implementation is based on StructureMap 2.5 AssemblyScanner by Jeremy Miller. Here are two tests showing the same bindings, but using different calls.
The x.Using() call takes an IBindingGenerator or you can pass it an instance: x.Using(new DefaultBindingGenerator()). Binding generators process types and add kernel bindings. For instance, the DefaultBindingGenerator processes types and looks for interfaces that match I[TypeName]. If a match is found, it binds I[TypeName] to the implementation TypeName. There are other binding generators that can use regex patterns to bind classes and to close generic interfaces:
There is really too much to talk about in a single post, but in looking through the IAssemblyScanner interface, you should get a decent idea of what it can do. The calls break down into: determine which assemblies to use, include or exclude types and namespaces from being candidates, automatically load Ninject modules, and run binding generators against all types being processed.
When processing assembly filters, a temporary AppDomain is spawned for the assembly processing so that if the predicate fails, we don’t have to worry about unneeded assemblies staying loaded in our application.
This has been a brief introduction to the conventions based binding extension for Ninject 2.0. I hope it is helpful in your configuration of the Ninject kernel.