Register your custom implementation, the sure way

The point of Episerver dependency injection is that you can plug in your custom implementation for, well almost, everything. But it can be tricky at times how to properly register your custom implementation.

The default DI framework (and possibly any other popular DI frameworks) works in the way that implementation registered later wins, i.e. it overrides any other implementation registered before it. To make Episerver uses your implementation, you have to make sure yours is registered last.

  • Never register your customer implementation using ServiceConfiguration. Implementation with that attributes will be registered first in the initialization pipeline. You will run into either
    • The default implementation was registered in an IConfigurableModule.ConfigureContainer , which means it will override yours
    • The default implementation was also registered using ServiceConfiguration. As those will be registered than any implementation using ServiceConfiguration , yours will be overridden by the default ones.
  • That leaves you with registering your implementation by IConfigurableModule.ConfigureContainer . In many cases, registering your implementations here will just work, because the default implementations are registered by ServiceConfiguration attribute. However, that is not always the case. There is a possibility that the default one was registered using IConfigurableModule.ConfigureContainer, and things will be tricky. First of all, unlike IInitializationModule when you can make your module depends on a specific module, the order in which IConfigurationModule.ConfigureContainer is executed is not determined. Even if you were allowed to make the dependency, it’s not clear which module you should depend on, and in many cases, that module is internal, so you can’t specify it

That is the point of this post then. To make sure your implementation is registered regardless of how the default one is registered, you can always fallback to use the ConfigurationComplete event of ServiceConfigurationContext. This is called once all ConfigureContainer have been called, so you can be sure that the default implementation is registered – time to override it then!

        public void ConfigureContainer(ServiceConfigurationContext context)
        {
            context.ConfigurationComplete += Context_ConfigurationComplete;
        }

        private void Context_ConfigurationComplete(object sender, ServiceConfigurationEventArgs e)
        {
            e.Services.AddSingleton<IOrderRepository, CustomOrderRepository>();
        }

Simple as that!

Note that this only applies to cases when you want to override the default implementation. If you register an implementation of your own interfaces/abstract classes, or you will be adding your implementation (not overriding the default one, an example is if you have an implementation of IShippingPlugin), you can register it in any way.

3 thoughts on “Register your custom implementation, the sure way

  1. Nice and neat tip. Should Epi consider to limit ways of dependency registration in the future? If ServiceConfiguration attribute is primarily used by Epi team, should this be kept as internal? Personally, I found it’s very hard to keep track of the dependencies registration once the solution has mixed up with different styles.

    1. I have heard people expressing the same thing (like to have all registrations in one place, hate the clusters created by ServiceConfiguration etc.). It might be a good idea to make it internal, but that is a breaking change and by the semantic version it’d require a new major CMS version. CMS 12, however, will not happen anytime soon.
      On other hand it’s one option and if you don’t like it, you can just not use it.

Leave a Reply to vimvq1987 Cancel reply

Your email address will not be published. Required fields are marked *