Trust Issues

After developing a new Outlook VSTO add-in, I noticed that at the first start after installing it (by the MSI method), Outlook would display a trust warning. The add-in is unsigned, but this should still not happen based on my experience from other add-ins.

As it turns out, there are two ways to “grant trust to the solution”:

• Sign the add-in
• Install it into the Program Files directory

The latter presumably works because Office assumes that write access to Program Files is sufficient evidence of administrative intent.

My installation path was C:\Program Files\Some Company\SomeAddin.

Huh. Now what?

…

… oh no, they didn’t …

… yes, they did.

Can you guess?

S
P
O
I
L
E
R

S
P
A
C
E

OK, a hint. The “Program Files” directory?

S
P
O
I
L
E
R

S
P
A
C
E

Either you have figured it out by now, or are hungry for the solution (because why else would you still be reading this?), so here it is:

The “Program Files” directory they talk about is the same “Program Files” directory that Office is installed in. My scenario involved a .NET assembly compiled to MSIL, so naturally I put it into the 64-bit Program Files directory because that one is more native to the system. The Office installation, however, was still 32-bit, and Outlook came to the (well, partially) unreasonable conclusion that:

"C:\Program Files\" != "C:\Program Files (x86)\"

Therefore the add-in was not installed in the Program Files directory, and therefore not to be trusted by default.