How to configure Simple Injector depending on build configuration

Question

I want to be able, to configure Simple Injector differently for each developer (for prototyping purposes for example). The default configuration should be hardcoded, of course.

I have used Unity before, and there I was able to overwrite the hardcoded registrations by an XML configuration file. This config file was not under source control, and so other developers could overwrite the hardcoded registrations with their custom registrations without interfering with others.

The developers should not need to submit their configuration to source control.

Is such a scenario supported by Simple Injector ? Is there any best practice for such a scenario ? Does this make sense at all, or is there a better way to achieve what I want?

Answer 1

One of the design decisions for Simple Injector is to not support XML based configuration out-of-the-box. This decision is described here but can be summarizes as:

XML based configuration is brittle, error prone and always provides a subset of what you can achieve with code based configuration. General consensus is to use code based configuration as much as possible and only fall back to file based configuration for the parts of the configuration that really need to be customizable after deployment. These are normally just a few registrations since the majority of changes would still require developer interaction (write unit tests or recompile for instance). Even for those few lines that do need to be configurable, it’s a bad idea to require the fully qualified type name in a configuration file. A configuration switch (true/false or simple enum) is more than enough. You can read the configured value in your code based configuration, this allows you to keep the type names in your code. This allows you to refactor easily, gives you compile-time support and is much more friendly to the person having to change this configuration file.

This however doesn't completely satisfy your requirements, since you don't want to "customizable after deployment". Instead, you want to customize per developer.

For this particular case, you shouldn't fall back on XML based configuration IMO. Just as you can exclude xml files using .gitignore, you can do the same with code based configuration files that developers can change, and that will compile with the rest of the application. Here's an example:

// Global.cs
public void Application_Start() {
    var container = new Container();

    // Default configuration here

    container.Options.AllowOverridingRegistrations = true;
    DeveloperOverrides.ApplyOverrides(container);
    container.Options.AllowOverridingRegistrations = false;

    DependencyResolver.Current = new SimpleInjectorDependencyResolver(container);
}

// DeveloperOverrides.cs
public static class DeveloperOverrides {
    public static void ApplyOverrides(Container container) {
    }
}

These two files can be checked in, where the DeveloperOverrides.ApplyOverrides method is left blank. After that you add the exclusion of the DeveloperOverrides.cs to your .gitignore file.

After this, developers can add their own overrides that are checked by the compiler, but are never checked in into source control:

// DeveloperOverrides.cs
public static class DeveloperOverrides {
    public static void ApplyOverrides(Container container) {
        container.Register<IMailSender, FakeMailSender>(Lifestyle.Singleton);
    }
}