.NET背景工作者在前景中看不到COM对象

Question

We are in the process of switching from one Mainframe 3270 client to another -- Attachmate Reflection to Bluezone. Reflection had a nice .NET API, but the only way to access Bluezone is through COM.

I have a common class in the solution that represents either a Reflection or a Bluezone object, and it grabs the existing client, whatever it happens to be, and communicates with it.

For the most part, everything is working fine. When I access the Bluezone COM object through any of the projects, it functions just like Reflection.

The problem appears to be when I access the Bluezone object within a background worker. The background worker doesn't appear to be able to see the COM object on the main thread.

When evaluating the COM object in debug mode, all of the properties show in error with the "The function evaluation requires all threads to run" error.

I know it's a long shot, but does anyone know of a way to manage this so I can access a foreground COM object within a background thread?

I've worked with the vendor on numerous issues, and they have been fantastic, but I have the feeling this may be a .NET/COM thing.

My last resort is to remove all of the background workers and make the users deal with the screen freeze, but I'd really hate to do that. My other option would be a to instantiate the COM object within the background worker, but there is a cost associated with this action. I tried to Marshal.GetActiveObject("") , but either it doesn't work or I don't know the right name of the application.

If anyone has had similar experiences with COM and background workers, I would welcome any insight.

Answer 1

This is very much by design for COM components. Very unlike .NET classes, COM keeps code thread-safe if the component tells COM that it doesn't support threading. Configured by the ThreadingModel registry key. And COM automatically ensures that this requirement is met by automatically marshaling the call, the equivalent of Invoke() in the .NET Framework.

So even though you make calls from your BackgroundWorker's DoWork() event handler, those calls don't run on the worker thread, they execute on the thread that the object was created on. If necessary an STA thread that COM creates.

The debugger knows this, it can "see" them just fine, it can tell that any watch expression is not going to be able to execute. Since it has frozen all the threads in the process, except for the debugger thread. So no can do, the message reminds you.

Just a debugging artifact. Maybe more, your BGW probably isn't very efficient or still causes the UI thread to hang. Check this post for code that creates a COM-friendly thread.