title: Why does having Office 2013 installed break the WinForms RichTextBox after using MAPI?
body: <p>I have three programs -</p>
  
  <p>Program 1: Microsoft Outlook Add-in that additionally uses MAPI. </p>
  
  <p>Program 2: Stand-alone exe that <strong>does not</strong> make any use of MAPI</p>
  
  <p>Program 3: Stand-alone exe that <strong>does</strong> make use of MAPI.</p>
  
  <p>All three programs are written in C# and make use of a WinForms RichTextBox at some point.</p>
  
  <p>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:</p>
  
  <pre><code>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()
  &lt;snip&gt;
  </code></pre>
  
  <p>Disassembling RichTextBox.get_CreateParams() reveals that it calls LoadLibrary on 'riched20.dll', then GetModuleFileName on the loaded module. </p>
  
  <p>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". </p>
  
  <p>The call to FileVersionInfo.GetVersionInfo() then fails because the path it was given does not exist. </p>
  
  <p>However - program 1 (the outlook-addin) has also loaded riched20.dll from the same path - and yet somehow that succeeds! </p>
  
  <p>Program 2 which does not load MAPI works fine, and it loads riched20.dll from C:\Windows\syswow62</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>All three programs work with prior versions of office.</p>
  
  <p>As a work-around, calling 'LoadLibrary("riched20.dll") myself prior to initializing MAPI makes the problem go away - but feels like a terrible hack.</p>
  
  <p>I also could not find any information about this 'vfs' file path and what it means on the Internet.</p>
  
  <p>For my own education, is anyone able to explain better what is going on here?</p>
  
  <p><strong>Update:</strong> I've got as far as working out it's something to do with the 'click-to-run' feature.</p>