none
Outlook plugin cannot locate dependant c++ DLL RRS feed

  • Question

  • We are working on an Outlook plugin written in C# that accesses some DLLs also written by ourselves.

    Here are the components (and their relationships):

    - F.dll - Written in C++.

    - MF.dll - Written in Managed C++.   Provides an interface to F.dll that can be used from .NET.   Depends on F.dll.

    - SEO.dll and SEO.vsto - Outlook plugin, written in C#.   Depends on MF.dll.

    When we attempt to run the plugin, we get the following exception:

    "System.IO.FileNotFoundException: Could not load file or assembly MF.dll or one of its dependencies.   The specified module could not be found."

    As far as we can tell, the issue is caused by the shadow copying of DLLs etc that Outlook does before running the plugin.  SEO.dll and MF.dll are being shadow copied.  F.dll is NOT being copied.

    I guess the question here is how do we get F.dll to be shadow copied by VSTOR as well as the other DLLs?

    The F.dll has been added to the project using "Add -> Existing Item" and its properties have been set as "Build Action = Content" and "Copy to Output Directory = Copy always".

    F.dll IS in the SEO.dll.manifest

    Our set up is:

    • Windows 7, 64 bit.
    • Visual Studio 2012.
    • Office 2007.

    Any suggestions would be most excellent!


    PS Just to verify that this is related to shadow copying, we were able to create a C# app that links the same DLLs, and it does not have the same error.
    • Edited by Jax1157 Thursday, January 31, 2013 11:57 PM
    Thursday, January 31, 2013 11:55 PM

Answers

  • Anyway, you problem is as follows:

    MF.dll is .net dll and its loading is managed via Fusion (engine for locating and loading of assemblies) - this mechanism knows and respects ProbePaths, PrivateBins, etc. Now when you call F.dll from MF.dll it is loaded via LoadLibrary which does not know nor care about .net, AppDomains, etc. As you have written that c++ dll, i;m sure you knw LoadLibrary searching algorithm - current dir, %PATH% ... As your process is outlook.exe, i;m sure you have guessed what current dir is. So either manually call LoadLibrary yourself using information from AppDomain to construct full path to your dll or place it somewhere where standard algorithm will find it.

    • Marked as answer by Jax1157 Thursday, February 7, 2013 3:40 AM
    Friday, February 1, 2013 7:45 AM

All replies

  • please verify that your installation folder for add-in contains F.dll and  folder from where vstor actually runs your add-in (you can see if in process monitor or by printing somewhere AppDomain.Current.BaseDirectory) does not. ShadowCopy mechanism is not 'picky' - it does not decide which files to copy, it should copy all files from add-in directory, so something went wrong. let us know of your findings.

    I think i might have explanation for this but let's first verify that F.dll is indeed there.

    Friday, February 1, 2013 5:03 AM
  • I can verify that F.dll is in the installation folder (C:\Program Files (x86)\MyApp\F.dll).

    It is definitely not in the vstor directory (C:\Users\Me\AppData\Local\assembly\dl3\...), however MF.dll and SEO.dll are there (in separate sub-directories)...

    So, no, it definitely isn't copying all of the DLLs from the installation directory.

    The same thing happens when running in Debug mode in VS2012 (i.e. before we even get to creating the MSI and installing) - MF.dll, SEO.dll (and others) are shadowed into C:\Users\...\assembly, but not F.dll

    Thank you for your help on this...

    Friday, February 1, 2013 6:02 AM
  • Anyway, you problem is as follows:

    MF.dll is .net dll and its loading is managed via Fusion (engine for locating and loading of assemblies) - this mechanism knows and respects ProbePaths, PrivateBins, etc. Now when you call F.dll from MF.dll it is loaded via LoadLibrary which does not know nor care about .net, AppDomains, etc. As you have written that c++ dll, i;m sure you knw LoadLibrary searching algorithm - current dir, %PATH% ... As your process is outlook.exe, i;m sure you have guessed what current dir is. So either manually call LoadLibrary yourself using information from AppDomain to construct full path to your dll or place it somewhere where standard algorithm will find it.

    • Marked as answer by Jax1157 Thursday, February 7, 2013 3:40 AM
    Friday, February 1, 2013 7:45 AM
  • Hi DamianD,

    Forgot to mention - Was able to get this working by adding the install directory to the system PATH.   A bit hacky, and will try and find another way around it, but in the meantime it does work.

    Wasn't able to add to System32, as the DLL does not have the necessary registration functions.

    Thanks for the help on this!

    Thursday, February 7, 2013 3:42 AM