c# - How to add reference to Outlook VSTO in a dynamic CSharpCodeProvider script

Question

I am trying to use an xml file to determine which outlook properties be should be included in a workflow executed via VSTO addin code.

Example

The xml might state that the Subject of the current Outlook.MailItem is required by the workflow. I haven't been able to use reflection to get the Subject property using its string name "Subject" because the MailItem is an interface and not a class.

I thought the solution might be to create and compile dynamic C# code that returns the required property by name...

Problem: I have been unable to work out how to find the location of the running Microsoft.Office.Interop.Outlook.dll so that I can add it as a reference to the dynamic compiler. I have tried a number of combinations, the last effort is shown below.

CodeDomProvider provider = new Microsoft.CSharp.CSharpCodeProvider();
CompilerParameters parameters = new CompilerParameters();
parameters.GenerateExecutable = false;
parameters.GenerateInMemory = true;
parameters.IncludeDebugInformation = false;
parameters.ReferencedAssemblies.Add(Assembly.GetAssembly(typeof(Outlook.MailItem)).Location);

Answer 1

parameters.ReferencedAssemblies.Add("Microsoft.Office.Interop.Outlook.dll");

Answer 2

I have the answer now. abatishchev gave me the confidence to know what should be working so I tried setting the compiler include path for the office dlls into the CompilerOptions.

I still need to work out how to get this path for the current version of outlook but that doesn't sound to hard or I might open a new question for it:)

Here is the code that works.

  parameters.ReferencedAssemblies.Add("Microsoft.Office.Interop.Outlook.dll"); 
  parameters.CompilerOptions = "/lib:\"C:\\Program Files (x86)\\Microsoft Visual Studio 11.0\\Visual Studio Tools for Office\\PIA\\Office14\"";`

Thanks abatishchev for all your help

UPDATE: Outlook addins use embedded interop assemblies which causes this problem. So it is not possible to determine office dll locations from loaded assemblies. The /lib path needs to be resolved by other means.