What we're missing is to actually create our container we'll be using in the app (the one and only instance), install our installer, and tell MVC infrastructure to use our controller factory instead of its own default. All of that happens in the
To do this let's add the following code, and invoke
method at the end of
private static IWindsorContainer container;
private static void BootstrapContainer()
container = new WindsorContainer()
var controllerFactory = new WindsorControllerFactory(container.Kernel);
We're instantiating the
class which is the core class in Windsor (as its name implies). We then call its
method. Reading it from inside out, the FromAssembly class
will look for, instantiate and return all installers in our assembly (this means our sole
for now, but in the future we'll have more). Then
will call down to each of those installers, which in turn will register the components specified by each installer.
If this sounds a bit too technical and is not very clear - don't worry. Once you start using it it'll all make sense
ReSharper says the installer is not being used
If you're using Resharper
or any other static analysis tool, you may notice it claims that your installers (and as you'll see later on, your services too) are not being used.
Do not be alarmed by that. Remember, those types are being used, but via a convention, so there's no hard
reference to them, which is what static analysis tools rely on.
We then create our
passing it the
wrapped by the container, and we attach the factory to MVC infrastructure.
We're also saving the container to a field. This is important, so that we can then clean up when the application ends (remember - clean up is as important as creation).
protected void Application_End()
The clean up means simply disposing of the container.
At this point you will have application that looks and behaves exactly like the default application that we started with. However, having Windsor in it opens new and exciting possibilities that we'll explore in Part five