Why does having Office 2013 installed break the WinForms RichTextBox after using MAPI?

Question

I have three programs -

Program 1: Microsoft Outlook Add-in that additionally uses MAPI.

Program 2: Stand-alone exe that does not make any use of MAPI

Program 3: Stand-alone exe that does make use of MAPI.

All three programs are written in C# and make use of a WinForms RichTextBox at some point.

On an x64 Windows 8 installation with Office 365 programs '1' and '3' have no issues, but program '2' crashes as soon as a RichTextBox control is constructed with the following stack:

System.IO.FileNotFoundException : C:\Program Files (x86)\Common Files\Microsoft Shared\Office15\riched20.dll
at System.Diagnostics.FileVersionInfo.GetVersionInfo(String fileName)
at System.Windows.Forms.RichTextBox.get_CreateParams()
at System.Windows.Forms.Control..ctor(Boolean autoInstallSyncContext)
at System.Windows.Forms.TextBoxBase..ctor()
at System.Windows.Forms.RichTextBox..ctor()
<snip>

Disassembling RichTextBox.get_CreateParams() reveals that it calls LoadLibrary on 'riched20.dll', then GetModuleFileName on the loaded module.

For Program 2, Visual Studio tells me that it has loaded riched20.dll from the path "C:\Program Files\Microsoft Office 15\root\vfs\ProgramFilesCommonX86\Microsoft Shared\OFFICE15\RICHED20.DLL".

The call to FileVersionInfo.GetVersionInfo() then fails because the path it was given does not exist.

However - program 1 (the outlook-addin) has also loaded riched20.dll from the same path - and yet somehow that succeeds!

Program 2 which does not load MAPI works fine, and it loads riched20.dll from C:\Windows\syswow62

Program 3 initializes MAPI before it creates a rich text box, and I know that certain MAPI functions will change your current working directory to the MAPI directory. This probably explains why program 3 loads office's riched20.dll and program 2 loads the system32 copy.

I suspect the difference between program 1 working and program 3 failing is that the vfs in the path stands for 'virtual file system' and so program 1, running as an Outlook addin, can somehow find the riched20.dll using a path that does not really exist.

All three programs work with prior versions of office.

As a work-around, calling 'LoadLibrary("riched20.dll") myself prior to initializing MAPI makes the problem go away - but feels like a terrible hack.

I also could not find any information about this 'vfs' file path and what it means on the Internet.

For my own education, is anyone able to explain better what is going on here?

Update: I've got as far as working out it's something to do with the 'click-to-run' feature.

Answer 1

The solution was to use pinvoke to call LoadLibrary on 'riched20.dll' prior to MAPI being initialized.

[DllImport("kernel32", SetLastError = true, CharSet = CharSet.Unicode)]
public static extern IntPtr LoadLibrary(string lpFileName);

LoadLibrary("riched20");