How can I use a .net assembly from another application's bin directory if it's not in the GAC?

Question

I'm developing a managed C++ application that will interface with another company's product. Their product is .net based, and the main API to use comes from a .net assembly, called foo.dll.

My application requires their product/s to be installed first. Installing their products yeilds three different applications, each in thier own directory, each with their own /bin directory, and each with local copies of the same .dll files, so you could find:

C:\company\product1\bin\foo.dll  
C:\company\product2\bin\foo.dll  
C:\company\product3\bin\foo.dll  

The company's told us which .dlls to use, and which ones they haven't put in the GAC when you install their product. Currently, I can get my application to run by copying their .dlls into my bin directory after building. Now that I'm looking to create an installer for my product, though, I'm running into difficulty finding an elegant way to deal with this. Assuming their API doesn't change, I should be able to run against most versions of their product, so long as the .dll I have matches the one their product is using on that machine.

Obviously, the ideal solution would be for them to put these assemblies in the GAC when you install their product, particularly since they share them themselves, but this isn't likely to happen, as their product is still immature, with lots of more important problems, and what they do works for them.

So I'm left with the problem of how to find and use the .dll I need when I install my product. The options I've come up with so far are the following:

1. Include their .dlls in my installer

   • Bad, because this locks me to a particular build of their software, and we're getting incremental development builds from them anyway, which won't match their public release.

2. Have my installer locate their installation directory and run gacutil.exe and whatever else is needed to put the .dlls in the GAC.

   • Bad, because gacutil.exe is only supposed to be for development, and it means we'd have to include it in our installer and install it along with our own product. It could also then interfere with their products finding the assemblies.

3. Have my installer locate their installation directory and copy the .dlls I need into my own directories.

   • Simple, it works, but is inelegant, and means my application could break if their product has even a minor update made to it until the new .dlls are copied over. I'd also like to avoid the need to copy files around.

4. Use the code I found at http://www.roelvanlisdonk.nl/?p=713 to programatically add their install directory to my application's .net search path at runtime.

   • Reasonaby simple if it works, but more code to maintain. So far it seems the only route to automatically load the dlls from their directory.

Managed C++ and .net is still relatively new to me, most of my coding has been linux-based C++. The feeling I have, is that it's going to be very difficult, because the other company isn't correctly managing how they use their .net assemblies if they want other people to be able to develop against them.

Has anyone with more experience had to deal with something like this and found a way around it?

Answer 1

Maybe you can solve this by making symbolic links to .dlls in question ? This way your app will be able to see and use the files and you are using their physical files on disk. If they update the files (correct some bugs) but are still backward compatible you will be able to automatically use their new code/.dlls.

The main problem here is if the assemblies in question are meant to be used from other aps ? Will their API be stable ? If not, basically there is nothing you can do.

Additionally, if you add their directories to your assembly search loading path you can non intentionally load wrong assembly because there can be multiple assemblies in future named X.dll.