How a native C++ plug-in DLL can load a private assembly located in a specific directory

Question

I have a native C++ DLL which is used as a plug-in in another application. This DLL has an embedded manifest and depends on a private assembly located in a folder external to the application. The application fails to load my plug-in DLL because my DLL depends on a private assembly which is never found (it is not located in the application directory, nor in the winsxs folder but in my plug-in directory whose location is not controlled by the application). The question is: how is it possible to make the system find my private assembly which is located in my own specific directory ? As an analogy, I would need an equivalent of setDllDirectory() but for assemblies. Or another way so that the system find my private assembly.

Constraints:

Because my DLL is a plug-in, I cannot install anything in the directory and sub-directories of the application. I also cannot modify the behavior of the application.
I would like to avoid sharing the assembly in winsxs.
I also have to use an assembly and not a simple DLL (that I could load with LoadLibrary) to avoid version conflicts.

Thanks.

Answer 1

you need to have a global location where you could give a list of directories that form your (from java-terminology) class-path. Once you have this list just traverse the directories looking for dll's.

I have used the Registry in windows for this. An environment variable or the /etc folder under linux would also do.

This is how linkers do it, and this is one way that the .NET GAC does (it specifies a list of directories in a registry key).

-- edit 1 --

Your problem seems quite a uncomfortable mix, it's like trying to eat with a straight jacket on :P. Why don't you drop the assembly requirement and have a function in a native DLL that returns a version identifier (name-version), and then have some application logic to determine if it may use the DLL.

For example file-name (fn) = monkey-1-1 and a function call returns a struct:

struct version-id
{
   const char * name;
   int major_number;
   int minor_number;
};

Then fn monkey-1-2 would not conflict on file-name or internal conversioning. and your programming conventions or application logic would make sure no adverse collisions occur.