The title sucks, but then again, the problem isn't simple.
I have a program that downloads some data from a web service and checks it. This is written in .NET5. It works perfectly in debug or release versions while in VS, but does not work any other way, and the difference is quite telling and peculiar.
The way the program works is that the user can choose one or more items from a listbox. They then press a button. For each item selected, a BackGroundWorker is launched to get data from a service for that item. This data will cover a series of pages, so I have to download each page in turn. Each page is then passed to a Task for processing. Therefore, for each item there will be from 1 to 20 Tasks started, one per page.
All those tasks are started in the DoWork handler of the BGW, with one BGW per item selected. At the end of the DoWork, there's a WaitAll on the Tasks, such that when they all finish, the RunWorkerCompleted event for the BGW is called.
That's a fair amount of threading that could be happening. One or more BGW's, each starting 1 or more Tasks, then waiting for all the Tasks to complete before the BGW itself completes.
There is something that needs to be done when ALL the BGW's complete, so I create a form level integer variable to hold the number of tables, and in the RunWorkerCompleted event handler, I call Interlock.Decrement on the variable. When that gets to 0, then all BGW's have completed.
As I said, this is all working in Debug or Release version while in VS. One further point is that once all of this has completed, a DGV on the form shows the results of all the work. A datatable is being populated by the Tasks (in a thread safe fashion). That datatable is bound to the DGV. In VS, nothing shows up until all the BGW's and their Tasks have completed, at which point, the results appear in the form.
While results are being processed, a form is shown that changes information and color to show progress. This is updated in the ProgressChanged event of the BGWs. This looks a bit ugly, in practice, because all the different BGWs share the same ProgressChanged event handler, but nobody cares, cause all they care about is that progress is happening. This form is one of the telling points about the issue, though.
Once again, all of this is working as expected while in VS, whether Debug or Release.
I then took the program and tried to run it outside of VS. The program runs as expected at first. I can select one or more items, then press the button to start processing them. However, unlike in VS, results start showing up right away. They are being added to the result table, and that table is bound to the DGV, so I'm fine with them showing up right away, but this is different from the behavior in VS.
The real problem is that the BGW's, even if only one, never complete. The RunWorkerCompleted event appears to never be raised. The wait form shows that the progress has made it to the final page, which is where it might pause, but the RunWorkerCompleted should hide that form, and the form is never hidden.
I suspected that this might be because the table counter was not being decremented properly, so in the very first rows of the RunWorkerCompleted, I added this:
I set the count into a label and force a refresh. I do that again after the decrement. In VS, it shows that the count is being properly decremented. It is not being properly decremented in production.
This does not prove that RunWorkerCompleted is not being fired, so I changed that code to set the label to something else (the word 'blue') in the RunWorkerCompleted event. The word Blue did not show up. That does prove that RunWorkerCompleted is not being raised.
So, I have different behavior:
1) The datatable is showing up in the DGV along the way, rather than only at the end. This is unimportant, but it IS a difference from the behavior in VS.
2) The RunWorkerCompleted event is never being called by any of the BGW when not running in VS, though it works fine in VS.
What is going on?
I have a program that downloads some data from a web service and checks it. This is written in .NET5. It works perfectly in debug or release versions while in VS, but does not work any other way, and the difference is quite telling and peculiar.
The way the program works is that the user can choose one or more items from a listbox. They then press a button. For each item selected, a BackGroundWorker is launched to get data from a service for that item. This data will cover a series of pages, so I have to download each page in turn. Each page is then passed to a Task for processing. Therefore, for each item there will be from 1 to 20 Tasks started, one per page.
All those tasks are started in the DoWork handler of the BGW, with one BGW per item selected. At the end of the DoWork, there's a WaitAll on the Tasks, such that when they all finish, the RunWorkerCompleted event for the BGW is called.
That's a fair amount of threading that could be happening. One or more BGW's, each starting 1 or more Tasks, then waiting for all the Tasks to complete before the BGW itself completes.
There is something that needs to be done when ALL the BGW's complete, so I create a form level integer variable to hold the number of tables, and in the RunWorkerCompleted event handler, I call Interlock.Decrement on the variable. When that gets to 0, then all BGW's have completed.
As I said, this is all working in Debug or Release version while in VS. One further point is that once all of this has completed, a DGV on the form shows the results of all the work. A datatable is being populated by the Tasks (in a thread safe fashion). That datatable is bound to the DGV. In VS, nothing shows up until all the BGW's and their Tasks have completed, at which point, the results appear in the form.
While results are being processed, a form is shown that changes information and color to show progress. This is updated in the ProgressChanged event of the BGWs. This looks a bit ugly, in practice, because all the different BGWs share the same ProgressChanged event handler, but nobody cares, cause all they care about is that progress is happening. This form is one of the telling points about the issue, though.
Once again, all of this is working as expected while in VS, whether Debug or Release.
I then took the program and tried to run it outside of VS. The program runs as expected at first. I can select one or more items, then press the button to start processing them. However, unlike in VS, results start showing up right away. They are being added to the result table, and that table is bound to the DGV, so I'm fine with them showing up right away, but this is different from the behavior in VS.
The real problem is that the BGW's, even if only one, never complete. The RunWorkerCompleted event appears to never be raised. The wait form shows that the progress has made it to the final page, which is where it might pause, but the RunWorkerCompleted should hide that form, and the form is never hidden.
I suspected that this might be because the table counter was not being decremented properly, so in the very first rows of the RunWorkerCompleted, I added this:
Code:
lformcount.text = mTableCount.ToString
lFormCount.Refresh()This does not prove that RunWorkerCompleted is not being fired, so I changed that code to set the label to something else (the word 'blue') in the RunWorkerCompleted event. The word Blue did not show up. That does prove that RunWorkerCompleted is not being raised.
So, I have different behavior:
1) The datatable is showing up in the DGV along the way, rather than only at the end. This is unimportant, but it IS a difference from the behavior in VS.
2) The RunWorkerCompleted event is never being called by any of the BGW when not running in VS, though it works fine in VS.
What is going on?