Dependency Injection for CMSApp and ITask, manual execution missing HttpContext.Current

Looks like this problem is related to the execution of the task outside of an HTTP request context and the code's reliance on the existence of HttpContext.Current to retrieve the Autofac container.

It would appear that different methods of executing the tasks (manual or scheduled and both options with/without separate threads) result in differences in the availability of HttpContext.Current.

I believe access to the container for all scenarios can be fixed through an additional accessor method in the Global.asax.cs file, exposing the container directly rather than through HttpContext.Current.

Autofac's documentation uses a static container which it exposes via a public property:

public class Global : HttpApplication, IContainerProviderAccessor
{
  // Provider that holds the application container.
  static IContainerProvider _containerProvider;

  // Instance property that will be used by Autofac HttpModules
  // to resolve and inject dependencies.
  public IContainerProvider ContainerProvider
  {
    get { return _containerProvider; }
  }
  ...
}

https://autofac.readthedocs.io/en/latest/integration/webforms.html#implement-icontainerprovideraccessor-in-global-asax

I would assume that a public static method returning the same static container may allow access to that container outside of HttpContext.Current.

This appears to work, my task runs in a thread and can resolve the services I currently rely on.

I assume that this approach may raise other issues related to the absence of the context and potentially also with the scoping of services.

I would be welcome to hear any comments on the above.

Thanks.

Dean,

This is one of the major issues with DI in the CMS WebForms applications. A traditional WebForms app could use Autofac's integration with mild success (though WebForms was never designed for DI so it's always going to be an awkward fit).

Kentico Xperience has an internal DI container that can be interacted with in both the ASPNET Core app (though normal DI) and through the CMS app (using service location).

The service location syntax looks like this:

var service = Service.Resolve<IActivityLogService>();

This container does not support scoped services (which means it doesn't need an HttpContext to function correctly).

You can read more about interacting with the internal DI system here:

• https://docs.xperience.io/custom-development/decorating-system-services
• https://docs.xperience.io/custom-development/customizing-providers/registering-providers-using-assembly-attributes

One of the MVPs wrote about this topic:

• https://bluemodus.com/articles/cross-platform-net-dependency-injection-in-kentico-xperience-13

As did I:

• https://dev.to/seangwright/kentico-12-design-patterns-part-4-adding-dependency-injection-to-the-cms-35a

I have read all those articles but still struggle to find the 'correct' way to implement Dependency Injection into the CMS. This is because we have one solution (and shared projects) which expose services and the necessary di registrations for both CMS & MVC like so:

// file: MyProject.Business.ServiceCollectionExtensions
namespace Microsoft.Extensions.DependencyInjection
{
    public static class ServiceCollectionExtensions
    {
        public static IServiceCollection AddMyBusiness(this IServiceCollection services)
        {
            services.AddScoped<IMyBusiness, MyBusiness>();
        }
    }
}

This way we can do in the CMS as well in our MVC hosting site the following:

services.AddMyBusiness();

So we 'must' support scoped services too to. In our application start of the CMS we then do this:

MyBusiness.Common.ServiceLocator.ResolverFunction = (type) =>
{
    if (HttpContext.Current == null)
    {
        using (var scope = _serviceProvider.CreateScope())
        {
            return scope.ServiceProvider.GetService(type);
        }
    }
    else
    {
        return _serviceProvider.GetService(type);
    }
}

This creates a new scope for every requested service, so results practically in transient resolutions.

The other option would be to create a scope everytime I want to request services, something like this:

public class MyScheduledTask : ITask
{
    public string Execute(TaskInfo task)
    {
        var serviceProvider = MyBusiness.Common.ServiceLocator.Resolve<IServiceProvider>();
        using (var scope = serviceProvider.CreateScope())
        {
            var myService = scope.ServiceProvider.GetService<IMyService>();
            var myOtherService = scope.ServiceProvider.GetService<IMyOtherService>();
        }
    }
}