OOM.NET Part 4 – Don’t Thread On Me

Matt Stehle used to be on my team prior and had blogged on the usage of Outlook Object Model (OOM) under .NET. However, his blog is being closed and I am re-blogging his content here.

Patrick posted a discussion of multithreading with Outlook Object Model and why it doesn't help to make OOM calls on a separate thread...

"Outlook Object Model is run in a STA COM server. This means that all OOM calls are executed on the main thread...You don't gain any performance [when multithreading] because all the calls are going to run on the same thread anyway and you incur the overhead hit of doing the marshaling to begin with, so there's not really an advantage to multithreading Outlook Object Model."

The typical scenario is a VSTO or .NET Shared AddIn for Outlook that wants to do some kind of "background" processing of items in a separate thread as to not hold up the UI.  This other thread will have OOM code in it that loops through items, folders, or both.  This is the kind of thread that actually hurts performance - using OOM on a separate thread rather than the main thread.  If an AddIn makes use of separate threads for working with things outside Outlook such as a database, filesystem, etc. then these recommendations don't apply necessarily.

Creating new threads and even marshalling between them is pretty easy in .NET and like many things in .NET (and VB6 before it) is that this marshalling and threading is supposed to "just work".  Developers can get a lot of this working without really understanding what is going on and what is required to make this work.  An understanding of COM and what it means to STA like Outlook Object Model is required to come to the conclusions in Patrick's post.