I am creating an automated test running application. In this part of the application, I am working on a polling server. It works by constantly polling the web server to determine when a new automated test should be run (for nightly automated runs of our GUI application).
When the polling server sees a request, it downloads all the information necessary and then executes the test run in a background worker. The problem is that part of the test run has OLE, COM, and other calls (for example, Clipboard.Clear()
) that occur in the background worker thread. When one of these calls occurs, the following exception occurs:
Current thread must be set to single thread apartment (STA) mode before OLE calls can be made. Ensure that your Main function has STAThreadAttribute marked on it.
How can I mark a background worker thread as single thread apartment? The Main call in my Program.cs obviously already has that attribute.
This is not possible, BGW uses a threadpool thread. TP threads are always MTA, it cannot be changed. You will have to use a regular Thread, call SetApartmentState() before you start it. This thread also should pump a message loop, call Application.Run().
Maybe you ought to consider calling this code from the UI thread. Because in all likelihood, the COM server is running its methods on the UI thread anyway. Marshaling calls from a worker thread to the STA thread that created the COM server is automatic, COM takes care of it.
Or take the bull by the horns and marshal yourself. You can create your own STA thread to give the server a happy home. You'll find code in this post, be sure to create the COM object in your Initialize() override.
BackgroundWorker uses by default a ThreadPool thread, but you can override this behavior. First you need to define a custom SynchronizationContext:
And override the default SynchronizationContext, like this, before you use your BackgroundWorker:
NOTE: this can have performance effects on the rest of your application, so you might want to restrict the new Post implementation (for example using the state or d parameters).
I used +Conrad de Wet's idea and it worked great!
There is one small issue with that code though, you have to close the "this.Invoke....." like with a });
Here is Conrad de Wet's code with this fix:
I have not tested it, but if you invoke the WinForms Form, you should be back to the UI thread and most of the stuff should work again.
You normally set it by defining attributre
[STAThread()]
on the entry point (e.g. Static Main).