I have a Winform app which lists a batch of invoices in a gridview. The users select the batch and clicks a button, \"Generate Invoices\". The process takes about 4-5 mins.
The Background Worker Process has a limited number of threads (20 or 25, can't remember exactly), and using one of them will puts that thread out of action for 4-5 minutes. Generally its advised not to use the background worker process for long running tasks, however this is not really a problem if you're only running one thread at a time.
In an ideal world, I would probably create my own thread, however this takes effort and understanding.
If you have memory leaks in the worker, certainly background process.
A separate process will of course be safer: If it has any problems (crashing, infinite loops, leaks or whatever) - these problems will not affect the parent process.
This is the exact type of task for which BackgroundWorker is meant. You should just push this into a background worker, and allow it to run. This provides a simple way to update your progress bar, etc.
There is no reason to make your own thread for this. The ThreadPool via BackgroundWorker will work perfectly well.
Background worker is easier and was designed exactly for your case (check the first few lines of msdn).
So I would follow the KISS principle :)
In fact background worker is even faster than normal threads! Because it is backed by a thread pool so it avoids expensive thread recreation.
Regarding the limits mentioned by Jaimal Chohan: Because background worker is backed by thread pool it has limit of 25 parallel task but that should be enough for any gui applicaiton. (If you somehow exceed the number, further task will simply wait for others to complete)