Asynchronous call of inprocess COM-DLL from VSTO Excel Addin?

2
votes

I am developing an application level VSTO 4 Addin for Microsoft Excel 2007 / 2010. The result is a windows forms based DLL using .Net 4 Client Profile.

Now I have to use a legacy COM-DLL. It is no problem to set the reference and access the COM-Methods via COM-Interop from .Net.

But the the (synchronous) method I need to call can take a minute or longer to get back.

I know your answer: Use a worker thread...

I have used The Task Parallel Library to put the long lasting operation in a worker task and keep the GUI (Excel) responding.

But: The inprocess COM-Call (in the worker task/thread) still seems to block my GUI-Thread.

  • Why? Is it because Excel is always running as STA (Single Thread Apartment)?
  • How can I keep the Excel GUI responding?
  • Is there a way to make it really asynchronous?

Thanks for any answers,

Jörg

1
excelcomasynchronousvstoadd-in
I don't think there's a real solution. See All Outlook object model calls run on the main thread and Is ApplicationClass Thread Safe? – Andrei Smolin - Add-in Express
These are good links. So the answer is 'Yes - Excel is always running as STA'. This indeed makes asynchronous work tricky to implement. – Govert
I am facing a very similar issue...did you find an answer ? – SutharMonil
Not really. I am blocking the Excel GUI and show a ProgressBar form which I can keep on moving by ugly Sleep / DoEvents. But the blocking synchron call to my legacy COM-DLL (in a worker thread) still cannot be interrupted. Not even if I use (the even more ugly) TerminateThread or a WorkerThread.Abort. I have made some experiments using a .NET WCF Server Component to host to legacy COM-DLL. This would be the cleanest way I think but there is one more component in the game then... – jreichert

1 Answers

0
votes

Finally, I've found an answer to this topic:

I've readed a lot about COM Threading Models and then spoke to the developer of the COM-DLL I am calling as an InProc-Server.

Together we changed the threading model of the COM-DLL:

  • OLD (blocking): Single-Threaded Apartment (STA), (ThreadingModel=Apartment)
  • NEW (working): Multi-Threaded Apartment (MTA), (ThreadingModel=Free)

Since we have our own synchronization mechanisms in the COM-DLL, there are no problems caused by the missing synchronization via the standard Windows message queue.

Problem was, that even the UI Thread was idle and even if it did DoEvents, the important windows messages (WM_Paint, etc.) were not delivered.

Now they are. The UI is responding at every time and the call to the COM-DLL is still done in a worker thread (as mentioned above, it's a ThreadPool thread which is used by the Task Parallel Library).