MS Office COM Interop and thread safety with multiple UAC Users

Question

I'm using c# .NET to invoke MS com using the MSOFFICE com interop DLLs.

I know that Office com interops are not thread safe. However, would it be thread safe for a different user? I don't know enough about process isolation on Windows to know if this is a limitation from shared components like this in general, or of Office coms are just poorly written. For instance, invoking PPT and outputting a video actually opens PPT and it renders the video to AVI. I know they would collide using the same logged in user account, but would it be ok if a different logged in system user invoked the process?

I ask because I'd like to stage a test environment on a machine already hosting another app. IT is hard to test in theory because we are not gauranteed to get process collisions, but it could happen.

Works beautifully and runs for weeks and months.

An example of an invocation:

using Microsoft.Office.Core;
using Microsoft.Office.Interop.PowerPoint;

Application app = new Application();              
Presentations presList = app.Presentations;                
Presentation pres = null;
// ... do some stuff ...

    // then kill it. 
    private static bool KillPowerPoint()
    {
        Process[] prs = Process.GetProcesses();
        var killed = false;
        // do a bunch of stuff to kill the process ...
        return killed;
    }

Different processes are completely isolated from each other. Keep in mind that one use case for Office is to have more than one interactive user using the computer at one time. — John Saunders, Jun 14 '13 at 20:10
You get your own instance of PowerPoint. Nobody else is using it so thread-safety is no concern. Killing it unceremoniously like you do and still not having a problem is a pretty strong hint. — Hans Passant, Jun 14 '13 at 20:11

score 3 · Accepted Answer · answered Jun 15 '13 at 21:41

It's a common misunderstanding that the reason why Office is not supported on a server environment is because it is not "thread-safe". Not so. Among other things, the nature of COM inter-process communications pretty much takes care of that (well, under most reasonable usage patterns). Also, Microsoft makes sure that Office is fully supported on a multi-user environment, because they have every reason to enable Office under a Terminal Server supporting dozens of simultaneous users (for the right amount of license money).

The reason is that Office was specified, written and tested to be used in an interactive environment. Office applications will issue message boxes or dialog boxes under circumstances you can't control. It fully expects, by design, that there is a human being staring a the screen with a keyboard at hand, ready to respond to any prompt or notification.

We don't know what your application does, or how. As long as your testing and your application are interactive in nature (by which I mean that the user can interact with Office), running on a server shared with something else should be fine. If your application is not interactive in nature, then even a single user on a dedicated machine is likely to experience unexpected behavior or a crash, sooner or later.

It's actually been running conversions/transformations on PPT(x)/DOC(x)/EXCEL for two months as an automation with no problems. The 24/7 script enforces that no simultaneous office operations ever occur. I'm guessing the instability may come from the GUI components then interfering? That's not a problem in a multi-user setting then. — FlavorScape, Jun 17 '13 at 15:18

score 0 · Answer 2 · answered Jun 14 '13 at 20:47

COM Interop for office is a STA (Single Threaded Apartment). So, while it does not support multi-threading per-say, the COM serializes all incoming commands.

I think this was a problem with older office versions:

Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.

However, I think blocking or stability issues are not present when using > 2010 office coms.

"The Ole RPC protocol for marshalling to an STA involves packaging the call up and actually sending a message to a hidden window (which Ole supplies) in the server process. When the server dispatches that message, the Ole window's WndProc unwraps the message and executes the call. The message protocol enforces serialization. Incoming calls are queued up in the message queue and they are handled in sequence by the GUI thread."enter link description here

MS Office COM Interop and thread safety with multiple UAC Users

2 Answers2