Introduction

Task.Run was added in .NET 4.5, so in .NET 4.0 the usual replacement is Task.Factory.StartNew. That said, StartNew is not a drop-in mental equivalent unless you choose the scheduler carefully. If you want behavior close to Task.Run, you normally want the default task scheduler, not whatever current scheduler happens to be active.

The Closest Equivalent in .NET 4.0

A common pattern is:

1using System;
2using System.Threading.Tasks;
3
4class Program
5{
6    static void Main()
7    {
8        Task task = Task.Factory.StartNew(
9            () => DoWork(),
10            TaskCreationOptions.None,
11            TaskScheduler.Default);
12
13        task.Wait();
14    }
15
16    static void DoWork()
17    {
18        Console.WriteLine("Running on the thread pool");
19    }
20}

This is the closest practical replacement for Task.Run in .NET 4.0 because it explicitly schedules work on the default scheduler, which usually means the thread pool.

Why TaskScheduler.Default Matters

A naive StartNew call uses the current scheduler. In UI apps or custom task-scheduler scenarios, that may not be what you want.

Task.Factory.StartNew(() => DoWork());

This can behave differently depending on the execution context. If the goal is "queue this work to the thread pool," specifying TaskScheduler.Default removes ambiguity.

That is one of the biggest reasons Task.Run became popular later: it gave a clearer, safer default for offloading work.

Returning Results

StartNew also works with return values.

1using System;
2using System.Threading.Tasks;
3
4class Program
5{
6    static void Main()
7    {
8        Task<int> task = Task.Factory.StartNew(
9            () => 21 * 2,
10            TaskCreationOptions.None,
11            TaskScheduler.Default);
12
13        Console.WriteLine(task.Result);
14    }
15}

This behaves much like Task.Run(() => 21 * 2) would in later frameworks.

Use ThreadPool.QueueUserWorkItem Only for Simpler Fire-and-Forget Cases

If you do not need a Task result or continuation model, the thread pool API is another option.

1using System;
2using System.Threading;
3
4class Program
5{
6    static void Main()
7    {
8        ThreadPool.QueueUserWorkItem(_ => DoWork());
9        Console.ReadLine();
10    }
11
12    static void DoWork()
13    {
14        Console.WriteLine("ThreadPool work item running");
15    }
16}

This is lighter-weight in some cases, but it does not give you Task-based composition, continuations, or the same exception-handling model. If the code wants a task abstraction, StartNew is usually the better fit.

Be Careful with Long-Running Work

If the operation is truly long-running and not a normal thread-pool task, use the appropriate creation option deliberately.

Task.Factory.StartNew(
    () => DoLongRunningWork(),
    TaskCreationOptions.LongRunning);

This is not the normal replacement for Task.Run, but it is useful when the work would otherwise monopolize a thread-pool thread for too long.

Exception Handling Still Matters

One reason tasks are nicer than raw thread-pool work items is that exceptions are captured by the task and can be observed through Wait(), Result, or continuations.

If you use QueueUserWorkItem, exceptions behave less transparently and task composition gets harder. That is why many .NET 4.0 codebases preferred StartNew once TPL was available.

Common Pitfalls

• Using Task.Factory.StartNew without TaskScheduler.Default and assuming it always behaves like Task.Run.
• Reaching for ThreadPool.QueueUserWorkItem when the code really needs a Task result or continuation.
• Treating long-running CPU work as ordinary thread-pool work without thinking about scheduler impact.
• Blocking on tasks carelessly in UI code and then blaming the task API for responsiveness problems.
• Assuming StartNew and Task.Run are identical in every scheduling detail.

Summary

• In .NET 4.0, the closest replacement for Task.Run is usually Task.Factory.StartNew.
• To mimic Task.Run more closely, prefer TaskScheduler.Default.
• 'ThreadPool.QueueUserWorkItem is an option for simpler fire-and-forget work, but it is not a task abstraction.'
• Use TaskCreationOptions.LongRunning only when the workload really justifies it.
• The important difference is not only syntax. It is also scheduler behavior and task composition.