--- title: Dependency injection slug: cms-12/docs/dependency-injection docTags: createdAt: 2026-08-10T15:56:03.000Z --- Dependency injection (DI) in Optimizely Content Management System (CMS) is based on the DI framework in ASP.NET Core located in [Microsoft.Extensions.DependencyInjection](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-2.1) API. CMS is configured to use the default DI implementation in ASP.NET Core. The required code in `Program.cs` to connect the DI framework in ASP.NET Core with CMS is the call to the extension method `ConfigureCmsDefault()` as in the example below: ```csharp public static IHostBuilder CreateHostBuilder(string[] args) => Host.CreateDefaultBuilder(args) .ConfigureCmsDefaults() .ConfigureWebHostDefaults(webBuilder => { webBuilder.UseStartup(); }); ``` ## Custom dependency injection frameworks To use a different DI framework than the built-in, you should replace the call to `ConfigureCmsDefault()` with a call to `UseServiceProviderFactory`, passing in an instance of `ServiceLocatorProviderFactoryFacade`, that should encapsulate the actual implementation to use. The following example shows how to configure the application to use Autofac (given that there is a reference to the Autofac NuGet package): ```csharp public static IHostBuilder CreateHostBuilder(string[] args) => Host.CreateDefaultBuilder(args) .UseServiceProviderFactory(context => new ServiceLocatorProviderFactoryFacade(context, new AutofacServiceProviderFactory())); .ConfigureWebHostDefaults(webBuilder => { webBuilder.UseStartup(); }); ``` ## Implicit registration of services The following example shows how to use implicit registration by using the `ServiceConfiguration` attribute makes it easier to read classes because the registration is done in the same class as the implementation. The code is an example of registering a service as a transient service (instances are created every time) or as a singleton service (a single instance is re-used). ```csharp public interface IService { void Sample(); } [ServiceConfiguration(ServiceType = typeof(IService))] public class TransientService : IService { public void Sample() { throw new NotImplementedException(); } } [ServiceConfiguration( ServiceType = typeof(IService), Lifecycle = ServiceLifetime.Singleton)] public class SingletonService : IService { public void Sample() { throw new NotImplementedException(); } } ``` ## Explicit registration of services The following code shows examples of registering `IService` and its implementation Service using the `IServiceCollection` abstraction. Normally, service registrations are done in the `Startup` class or in an extension method like `AddCms`. The service registration abstraction is also available in initialization modules which implement the `IConfigurableModule` interface. There are convenient extension methods in namespaces `Microsoft.Extensions.DependencyInjection, Microsoft.Extensions.DependencyInjection.Extensions` and `EPiServer.ServiceLocation`. Inline comments describe the examples in more detail: ```csharp [InitializableModule] public class ModuleWithServices : IConfigurableModule { public void ConfigureContainer(ServiceConfigurationContext context) { // Register IService1 with implementation Service1, // create new instance every time context.Services.AddTransient(); // Register IService1 with implementation Service1, // re-use a single instance context.Services.AddSingleton(); // Register IService1 with custom factory context.Services.AddTransient((locator) => new Service()); // Register IService1 to be cached per scope, // e.g. HTTP request context.Services.AddScoped(); } public void Initialize(InitializationEngine context) { } public void Uninitialize(InitializationEngine context) { } } ``` ## ServiceLocator You should use dependency injection through constructors or use the DI container from a context like `HttpContext.RequestServices`. You can also use a static property `ServiceLocator.Current` to access the DI container in the rare places where there is no other way to get dependencies. If you use `ServiceLocator.Current` then if you use custom scopes, you should create the scopes using extension method `CreateServiceLocatorScope` instead of the extension method `CreateScope` within .NET Core. This gets the static accessor `ServiceLocator.Current` to be aware of the custom-created scope. ## Intercept existing services Sometimes, it is useful to intercept service calls, such as debugging or adding logging. By using the extension method `Intercept` on `IServiceCollection`, you can replace existing services with another implementation. The provided factory method will have access to the default instance of the service. If several implementations are registered for a service, registrations are intercepted. The interceptor service has the same scope as the intercepted service was registered with. This example shows an interceptor registration of the `ISynchronizedObjectInstanceCache` where the interceptor logs remote removals. ```csharp using EPiServer.Framework; using EPiServer.Framework.Cache; using EPiServer.Framework.Initialization; using EPiServer.Logging; using EPiServer.ServiceLocation; using System; namespace EPiServerSamples { [ModuleDependency(typeof(EPiServer.Web.InitializationModule))] public class LoggingInitializer : IConfigurableModule { public void ConfigureContainer(ServiceConfigurationContext context) { context.Services.Intercept((locator, defaultCache) => new LoggingSynchronizedCache(defaultCache)); } public void Initialize(InitializationEngine context) { } public void Uninitialize(InitializationEngine context) { } } public class LoggingSynchronizedCache : ISynchronizedObjectInstanceCache { private readonly ISynchronizedObjectInstanceCache _defaultCache; private readonly ILogger _log = LogManager.GetLogger(typeof(LoggingSynchronizedCache)); public LoggingSynchronizedCache(ISynchronizedObjectInstanceCache defaultCache) { _defaultCache = defaultCache; } public void RemoveRemote(string key) { if (_log.IsDebugEnabled()) { _log.Debug($"Remote removal called at '{DateTime.Now}' with key '{key}'"); } _defaultCache.RemoveRemote(key); } public IObjectInstanceCache ObjectInstanceCache => _defaultCache.ObjectInstanceCache; public FailureRecoveryAction SynchronizationFailedStrategy { get { return _defaultCache.SynchronizationFailedStrategy; } set { _defaultCache.SynchronizationFailedStrategy = value; } } public object Get(string key) => _defaultCache.Get(key); public void Insert(string key, object value, CacheEvictionPolicy evictionPolicy) => _defaultCache.Insert(key, value, evictionPolicy); public void Remove(string key) => _defaultCache.Remove(key); public void RemoveLocal(string key) => _defaultCache.RemoveLocal(key); } } ``` ## Dependency injection use case examples Optimizely CMS leverages Dependency Injection (DI) to manage the lifecycle and dependencies of services. Starting from CMS 12, which is built on ASP.NET Core, Optimizely fully integrates with the ASP.NET Core DI framework. The following sections show dependency injection patterns in Optimizely CMS: ### Constructor injection This is the most common and recommended pattern for DI in Optimizely CMS. You inject dependencies through the constructor of a class. The DI framework automatically provides the required services when the class is instantiated. **Best use case** – When your service class has mandatory dependencies that are required to perform its operations. ```csharp public class MyService { private readonly IContentLoader _contentLoader; public MyService(IContentLoader contentLoader) { _contentLoader = contentLoader; } public void SomeMethod() { var content = _contentLoader.Get(contentLink);   } } ``` ### Property injection In property injection, dependencies are injected into properties of the class, rather than through the constructor. The DI framework sets the properties after the object is created. **Best use case** – When a dependency is optional, or you want to delay the injection until after the object has been constructed. ```csharp public class MyService { [Inject] public IContentLoader ContentLoader { get; set; } public void SomeMethod() { var content = ContentLoader.Get(contentLink); } } ``` ### Method injection In method injection, dependencies are provided as parameters to a specific method. This pattern is not as common as constructor injection but can be used when dependencies are only needed for specific methods. **Best use case** – When a dependency is only required for a single method, or you want to provide different dependencies for different method calls. ```csharp public class MyService { public void SomeMethod(IContentLoader contentLoader) { var content = contentLoader.Get(contentLink); } } ``` ### Scoped injection Optimizely CMS supports the typical ASP.NET Core service lifetimes: Transient, Scoped, and Singleton. The Scoped lifetime is particularly useful in Optimizely for services that should be instantiated once per request. This is especially useful when dealing with HTTP context or request-specific data. See [.NET dependency injection](https://learn.microsoft.com/en-us/dotnet/core/extensions/dependency-injection) in the Microsoft documentation.