1

I'm working on a VSTO Addin for Outlook and using .Net TPL/PFX Library to access the OOM.

Here's a snippet:

Parallel.ForEach(mailItem.Recipients.OfType<Outlook.Recipient>(), x =>                    
{
    try
    {
        Outlook.Recipient recipient = x as Outlook.Recipient;
        ...

I've come across some threads here talking about OOM running in STA so wondering if the above is useful or in anyway degrades performance. Also, what type of Cleanup/ComRelease should be accounted for in such code?

Can any VSTO Outlook expert comment on this please?

Jeff B
  • 8,572
  • 17
  • 61
  • 140
SohoNYC75
  • 21
  • 2
  • Possible duplicate of [VSTO Outlook add-in, does UI manipulation need to be done from main thread?](https://stackoverflow.com/questions/29931477/vsto-outlook-add-in-does-ui-manipulation-need-to-be-done-from-main-thread) – Chris Nov 15 '17 at 20:16
  • This has nothing to do with UI manipulation. Im only trying to figure out if anyone knows that accessing the OOM in a multi-threaded environment is advisable or if it causes any other issues. Thanks! – SohoNYC75 Nov 16 '17 at 14:19
  • It applies to the entire object model, not just the UI. – Chris Nov 16 '17 at 15:00
  • Chris, So whats your answer?? Are you saying doing the above will cause an Issue or Not? – SohoNYC75 Nov 16 '17 at 20:42

1 Answers1

2

Outlook uses the single-threaded apartment model, so you should deal with it on the main thread only. If latest Outlook versions detect cross-threaded calls you may get an exception as a result of such operations. I'd suggest gathering the required information from the OOM on the main (UI) thread and then process it using secondary threads, for example, if you need to make some web calls.

Also you may consider using a low-level API on which Outlook is based on - Extended MAPI. It is allowed to use that API on secondary threads. For example, you may consider using third-party libraries that were built on top of Extended MAPI and support using it in multithreading environments, the most famous one is Redemption.

Eugene Astafiev
  • 47,483
  • 3
  • 24
  • 45