Windsor’s Nuget package and code – your input needed

As we’re nearing to release the next version of Castle Windsor I’m also thinking about how we could leverage Nuget better.

One idea I had was to include elements I (and most people) end up writing in every project using Windsor – a Bootstrapper class which is responsible for setting up the container, a folder for installers, and an installer in it.

This is what a solution would look like after creating an empty project and installing Windsor via Nuget:

Visual Studio after installing Windsor via Nuget, including code

Visual Studio after installing Windsor via Nuget

The goal of this would be to put the code in your solution having the bare-bone useful minimum, with intention you’d customize it as needed. Most people end up adding at least and so the bootstrapper would look like this:

using Castle.Facilities.TypedFactory;
using Castle.MicroKernel.Resolvers.SpecializedResolvers;
using Castle.Windsor;
using Castle.Windsor.Installer;

namespace WpfApplication1
{
    public class WindsorBootstrapper
    {
        public IWindsorContainer BuildContainer()
        {
            IWindsorContainer container = Instantiate();
            Configure(container);
            InstallComponents(container);
            return container;
        }

        private IWindsorContainer Instantiate()
        {
            return new WindsorContainer();
        }

        private void Configure(IWindsorContainer container)
        {
            container.AddFacility<TypedFactoryFacility>();

            var resolver = new CollectionResolver(container.Kernel, allowEmptyCollections: false);
            container.Kernel.Resolver.AddSubResolver(resolver);
        }

        private void InstallComponents(IWindsorContainer container)
        {
            container.Install(FromAssembly.This());
        }
    }
}

The installer is a tougher nut to crack. Because they are so specific to your application it’s impossible to create a generic one that will be useful. I’m thinking either about shooting for the widest scenario, and create either an empty one, with generic name like RepositoriesInstaller, or to get it one step farther and add some real-like code, but comment it out, like this:

using Castle.MicroKernel.Registration;
using Castle.MicroKernel.SubSystems.Configuration;
using Castle.Windsor;

namespace WpfApplication1.Installers
{
    public class RepositoriesInstaller : IWindsorInstaller
    {
        public void Install(IWindsorContainer container, IConfigurationStore store)
        {
            // Customize to the needs of your application

            //container.Register(Classes.FromThisAssembly()
            //                       .BasedOn(typeof (IRepository<>))
            //                       .WithService.Base()
            //                       .LifestyleTransient());
        }
    }
}

My hope is, this would give advanced users a jump-start and provide a gentle introduction for people new to Windsor, and push them towards established practices when using Windsor (closer to to the pit of success).

This is just an idea, and I would like to hear your feedback. What do you think about it? Do you think it should be included at all in the Castle.Windsor package, or should we create a separate package called something like Castle.Windsor-wc (for “with code”) for this?

Comments

Luke Hutton says:

Not a bad idea, but I would vote for keeping them separate. I have R# file & live templates to get the installers/installer tests going quite quickly. I would expect the nuget package for Castle.Windsor just to be a thin package containing the dlls.

hazzik says:

From my point of view it should be separated package. 

Cristiano says:

I like the idea of start-up template very much, but I vote for keep it separately.

Mark Seemann says:

While I can sympathize with the idea of providing a bit of more hand-holding for those who need it, I’d prefer that it wasn’t the default. In my opinion, exactly how you’d end up structuring your Castle Windsor code is not only personal and subjective, but also context-specific. In other words, I don’t believe a one-size-fits-all solution would be appropriate.

Perhaps another NuGet packages called something like Castle.Windsor.Scaffolding would be in order. That’s seems to be the popular name for these kinds of thinks these days.

Juanma says:

I’m not sure it’s a good idea to add another nuget package to include this templates. It could be confusing for newbies to have two different packages for (nearly) the same thing.

I prefer something like dependent packages with Bootstrapping code for different types of applications.

Castel.Windsor
+ Castle.Windsor.Bootstrapper // contains Bootstrapper and Installers folder like you showed 
++ Castle.Windsor.AspNetMvcBootstrapper // contains ControllersFactory and ControllersInstaller

Don’t like, better in a separate pkg

Matthew Nichols says:

I think this could be a nice Castle Windsor Quick Start package perhaps that have the main Windsor package as a dependency.  But not in the main package please.

wesmcclure says:

Please don’t add stuff to the core nuget packages, its very annoying during updates and new installs, a separate package makes sense

dbones says:

I agree with most of the comments, please could these be separate. I like the castle package as it is and for project template’s I use another technique.