Support Dependency Injection from Scheduler

[bdukes]

Description of problem

There is no way to access services in the Dependency Injection container from a scheduler client.

Description of solution

When DNN creates a scheduler client, it needs to use the DI container.

Additional context

Based in a discussion at https://dnncommunity.org/forums/aft/890 and via https://dnntag.slack.com/

[valadas]

I am not an expert at DI and I did not build code samples to test this so just asking questions :)

I was under the impression that we use Microsoft one unaltered so that something like:

public class MyScheduler : SchedulerClient
{
    protected IPortalController PortalController { get; }

    public MyScheduler(IPortalController portalController)
    {
        this.PortalController = portalController;
    }
}

would just work out of the box... Right?

Now for the forum post at hand, the major issue (which is not new) is that the scheduler has no HTTP Context and one needs to use another way to obtain the portalId (configuration, settings, etc.) to get a PortalInfo object manually from code.

[bdukes]

DNN currently supports constructor injection in 1️⃣ Web API controllers, 2️⃣ MVC controllers, 3️⃣ Razor models, and it supports "service location" in WebForms via PortalModuleBase.DependencyProvider.

Anywhere else that DNN is creating new instances of classes, dependency injection (neither constructor injection nor service location) is not yet supported. In this particular case, creating a SchedulerClient involves explicitly calling the constructor which takes a single ScheduleHistoryItem

Dnn.Platform/DNN Platform/Library/Services/Scheduling/ProcessGroup.cs

Lines 157 to 173 in c35fdc7

	private SchedulerClient GetSchedulerClient(string strProcess, ScheduleHistoryItem objScheduleHistoryItem)
	{
	//This is a method to encapsulate returning
	//an object whose class inherits SchedulerClient.
	Type t = BuildManager.GetType(strProcess, true, true);
	var param = new ScheduleHistoryItem[1];
	param[0] = objScheduleHistoryItem;
	var types = new Type[1];
	//Get the constructor for the Class
	types[0] = typeof (ScheduleHistoryItem);
	ConstructorInfo objConstructor;
	objConstructor = t.GetConstructor(types);
	//Return an instance of the class as an object
	return (SchedulerClient) objConstructor.Invoke(param);
	}

[mitchelsellers]

This one could be a bit interesting since we have an architecture requirement with the first parameter being the ScheduleHistoryItem. It is possible that we might have to do something different for this to support DI.

[dimarobert]

You could use ActivatorUtilities.CreateInstance(IServiceProvider, Type, Object[]), ActivatorUtilities.CreateInstance<T>(IServiceProvider, Object[]) or even ActivatorUtilities.CreateFactory(Type, Type[]) for repeated resolutions - it returns a reusable delegate object ObjectFactory(IServiceProvider serviceProvider, object[] arguments). The Object[] parameter is for additional constructor parameters that cannot be resolved from the ServiceProvider. In your case the ScheduleHistoryItem.

Another note, to preserve the lifetime of scoped services resolved in this manner (see details about the pitfalls of MS DI) you should open a scope from the Globals.DependencyProvider for each execution of the scheduler and resolve from it. You will also need to dispose it accordingly to avoid memory leaks. The safest way would be to wrap the creation and execution of a job in a using (var scope = sp.CreateScope()) block.
A good example of a scoped service would be the DbContext of EntityFramework.