Multithreaded service, BackgroundWorker vs ThreadPool?

The value in BackgroundWorker is that it can raise its ProgressChanged and RunworkerCompleted event on the thread that created its instance. Which makes it very convenient in programs that cannot support free threading.

For this to work properly, it is however required that the SynchronizationContext.Current property references a non-default synchronization provider. A provider which is responsible for marshaling calls from one thread to another. The .NET framework has two providers that are readily available: System.Windows.Forms.WindowsFormsSynchronizationContext and System.Windows.Threading.DispatcherSynchronizationContext. These providers handle synchronization for, respectively, Winforms and WPF.

There's a connection, Winforms and WPF are both class libraries that have a threading problem. Both implement GUIs and Windows based graphical user interfaces are fundamentally thread-unsafe. Windows windows can only be updated from the thread that created them. In other words, these custom synchronization providers exist because there's a dire need for them. Also notable is that they work by taking advantage of the way UI threads work. A UI thread executes code in an event driven way, pumping a message loop to receive notifications. The synchronization provider can inject calls to event handlers using this mechanism. This is no accident.

Back on topic, a Windows service has no such facility. It doesn't have a GUI and doesn't install a custom synchronization provider. As such, BackgroundWorker provides no feature that's useful in a service. Without the custom synchronization provider, the default provider simply runs events on a threadpool thread. Which is not useful, you might as well fire the event from your worker thread. Getting events to run on another specific thread is very difficult to achieve, unless you recreate the message loop mechanism or hook into the Winforms plumbing and create a simulated UI thread using an invisible window. Which is not entirely uncommon btw.

BackgroundWorker was designed to simplify interaction of the task working in the background thread with the UI. You will see the great answer on when to use BackGroundWorker, ThreadPool and simply Thread at BackgroundWorker vs background Thread

I think it answers the question :).