conditionally declare (DllImport) libraries at runtime

I have an application with several classes that make use of libraries that use P/Invoke (i.e. they are declared with the [DllImport] attribute).  

There are three different libraries (with largely identically defined functions) that I need to import from, depending on different circumstances.  For any given installation (or at least at runtime), I only need one of the three.  

What I'd like to do is set up an App.Config setting that would allow me to specify which library will be imported.  My question is whether and how is it possible to conditionally declare such external platform libraries ... without having to have three sets of classes that are indentical except for their library import statements.

It do not see a straight-forward way to apply any conditional logic to the declaration.  If there were such an opportunity, that would be ideal.  But, I'm thinking that there may be a way to accomplish something close to this outcome with class inheritance.  Is it possible to do something like create a base class which calls functions which are declared in the classes that inherit from it?  Perhaps this is overcomplicating the problem?

At any rate, I'd appreciate specific advice on how to achieve the goal of conditionally importing libraries.  Thanks.
Who is Participating?
You can't conditionally DllImport things.

What you might do is have 3 different .NET classes (or maybe even 3 assemblies with one class in each) that have the appropriate DllImport for each of the 3 different DLL's you wish to import.

Then, from your .NET code, you load up the correct .NET class that has the correct DLLImport.

The DllImport doesn't attempt to link against the actual DLL until you call a DllImport'd method, so the other classes should be safe to just have lying around when you're not using them in your process.

If that makes you feel dirty, you can do the other thing I suggested, which is to have 3 different assemblies and then your .NET code can conditionally load the correct assembly which has a class that DllImports the appropriate DLL.

This approach is handy because if you ever had other DLLs you wanted to load, you just add another assembly that handles that DLL and your main code doesn't have to change (at all if you do a good Factory pattern design, or much if you hard-code some things).
dannykroukAuthor Commented:
The key piece of information for me is the fact that the DllImport statement doesn't actually link against the dll ... that happens when the function is called.  I've found that I can alias my function names when I declare them, so I can effectively create unique function names for the functions from all of the libraries.  Then, I can use my App.Config parameter to tell me which ones to call.

Thanks for the clear explanation.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.