nopSolutions/nopCommerce · error · Exception

Schedule task ({scheduleTask.Type}) cannot by instantiated

Error message

Schedule task ({scheduleTask.Type}) cannot by instantiated

What it means

Thrown by ScheduleTaskRunner.PerformTaskAsync when the schedule task's type cannot be resolved at runtime. It first tries Type.GetType(scheduleTask.Type), then falls back to scanning all loaded assemblies via AppDomain.CurrentDomain.GetAssemblies().Select(a=>a.GetType(...)). If both yield null, it throws. This means the configured type string does not match any type in any loaded assembly.

Source

Thrown at src/Libraries/Nop.Services/ScheduleTasks/ScheduleTaskRunner.cs:53

        _logger = logger;
        _scheduleTaskService = scheduleTaskService;
        _storeContext = storeContext;
    }

    #endregion

    #region Utilities

    /// <summary>
    /// Initialize and execute task
    /// </summary>
    protected virtual async Task PerformTaskAsync(ScheduleTask scheduleTask)
    {
        var type = (Type.GetType(scheduleTask.Type) ??
                    //ensure that it works fine when only the type name is specified (do not require fully qualified names)
                    AppDomain.CurrentDomain.GetAssemblies()
                        .Select(a => a.GetType(scheduleTask.Type))
                        .FirstOrDefault(t => t != null)) ?? throw new Exception($"Schedule task ({scheduleTask.Type}) cannot by instantiated");

        object instance = null;

        try
        {
            instance = EngineContext.Current.Resolve(type);
        }
        catch
        {
            // ignored
        }

        instance ??= EngineContext.Current.ResolveUnregistered(type);

        if (instance is not IScheduleTask task)
            return;

        scheduleTask.LastStartUtc = DateTime.UtcNow;

View on GitHub (pinned to 64bdf2ff08)

Solutions

  1. In the database ScheduleTask table, correct the [Type] column to the exact fully-qualified type name that currently exists (use typeof(MyTask).FullName).
  2. Ensure the plugin/assembly containing the task is installed and actually loaded (check loaded assemblies; fix any load errors).
  3. If the task is obsolete, delete the ScheduleTask row rather than leaving a dangling reference.
  4. Verify the type has a public constructor resolvable by the DI container (EngineContext.Current.Resolve).

Example fix

// before (DB): Type = "Nop.MyOldNs.SendEmailsTask, Nop.MyOldAssembly"
// after  (DB): Type = typeof(MyNewNs.SendEmailsTask).FullName
//             e.g. "Nop.MyNewNs.SendEmailsTask, Nop.MyNewAssembly"
Defensive patterns

Strategy: validation

Validate before calling

var type = Type.GetType(task.Type)
    ?? AppDomain.CurrentDomain.GetAssemblies().Select(a => a.GetType(task.Type)).FirstOrDefault(t => t is not null);
if (type is null) { logger.Warn($"Task type not found: {task.Type}"); /* skip or disable task */ return; }

Type guard

static bool IsTaskTypeResolvable(string typeString) =>
    Type.GetType(typeString) is not null
    || AppDomain.CurrentDomain.GetAssemblies().Any(a => a.GetType(typeString) is not null);

Try / catch

try { await runner.ExecuteAsync(task); }
catch (Exception ex) when (ex.Message.Contains("cannot by instantiated"))
{ logger.Error($"Schedule task type unresolved: {task.Type}", ex); }

Prevention

When it happens

Trigger: A ScheduleTask row references a Type string that is misspelled, namespace-changed, in an assembly that is not loaded, or belongs to a plugin that was uninstalled/disabled. Also triggers after a rename/refactor where the DB still holds the old fully-qualified type name.

Common situations: Upgrading nopCommerce and a task type was renamed/moved; uninstalling a plugin whose task row remains in the ScheduleTask table; typo in a custom task's Type column; assembly load failure keeping the plugin's assembly out of the AppDomain.

Related errors

AI-assisted analysis of nopSolutions/nopCommerce@64bdf2ff08 (2026-08-13). Data as JSON: /api/errors/13a0c9bc372ff72c. Report an issue: GitHub.