Pourquoi l'installation d'Office 2013 rompt-elle le WinForms RichTextBox après l'utilisation de MAPI?

Question

J'ai trois programmes -

Programme 1: Complément Microsoft Outlook qui utilise en plus MAPI.

Programme 2: exe autonome qui ne pas faire usage de MAPI

Programme 3: Stand-alone exe que -t faire usage de MAPI.

Les trois programmes sont écrits en C# et utilisent WinForms RichTextBox à un moment donné.

Sur une installation de Windows x64 8 avec Office 365 programmes « 1 » et « 3 » ont pas de problèmes, mais le programme se bloque « 2 » dès qu'un contrôle RichTextBox est construit avec la pile suivante:

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> 

Désassembler RichTextBox.get_CreateParams() indique qu'il appelle LoadLibrary sur 'riched20.dll', puis sur GetModuleFileName sur le module chargé. Pour le programme 2, Visual Studio m'indique qu'il a chargé riched20.dll à partir du chemin d'accès "C: \ Program Files \ Microsoft Office 15 \ root \ vfs \ ProgramFilesCommonX86 \ Microsoft partagé \ OFFICE15 \ RICHED20.DLL".

L'appel à FileVersionInfo.GetVersionInfo() échoue ensuite car le chemin qu'il a reçu n'existe pas.

Cependant - le programme 1 (le outlook-addin) a également chargé riched20.dll du même chemin - et pourtant cela réussit!

programme 2 qui ne fonctionne MAPI charge pas bien, et il charge riched20.dll de C: \ Windows \ syswow62

Programme 3 initialise MAPI avant de créer une zone de texte riche, et je sais que certaines fonctions MAPI va changer votre répertoire de travail actuel dans le répertoire MAPI. Cela explique probablement pourquoi le programme 3 charge riched20.dll du bureau et le programme 2 charge la copie system32. Je suspecte la différence entre le programme 1 fonctionnant et le programme 3 échouant est que le vfs dans le chemin représente le «système de fichiers virtuel» et ainsi le programme 1, fonctionnant comme un addin d'Outlook, peut en quelque sorte trouver le riched20.dll using un chemin qui n'existe pas vraiment.

Les trois programmes fonctionnent avec les versions antérieures de bureau. En tant que solution de rechange, appeler moi-même LoadLibrary ("riched20.dll") avant l'initialisation de MAPI fait disparaître le problème, mais me semble être un hack terrible.

Je n'ai pas non plus trouvé d'informations sur ce chemin de fichier 'vfs' et ce que cela signifie sur Internet.

Pour ma propre éducation, quelqu'un peut-il expliquer mieux ce qui se passe ici?

Mise à jour: Je n'ai pas d'autre choix que de travailler avec la fonction «cliquer pour exécuter».

Answer 1

La solution consistait à utiliser pinvoke pour appeler LoadLibrary sur 'riched20.dll' avant l'initialisation de MAPI.

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

LoadLibrary("riched20");