none
Using dynamic parameter as filename for DllImport RRS feed

  • Question


  • Hello,

    I have inherited some old code with a bunch of C-interfaced DLL plugins. Each Dll exposes a few functions by name that I want to used from native code.

    I would like to write my managed code using the plugin dll something like this:

    class Plugin : IDisposable
    
    {
    
        const string filename = "plugin_1.dll";
    
    
    
        [DllImport(dllname)]
    
        static extern IntPtr Method_A();
    
    
    
        // A bunch of more methods exist
    
    }
    
    

    In the Plugin class, I would of course expose managed function that uses the private imported methods from the C dll. 


    Something like this would work for one (1) plugin. But how can provide the Dll name as a string to the constructor (or some templete-like argument)?

     

    I would ideally like to use the plugins like this:

    (A):
     Plugin plugin1 = new Plugin("Plugin_1.dll");
     Plugin plugin2 = new Plugin("Plugin_2.dll");
     
    or

    (B):
     Plugin<string> plugin1 = new Plugin<"Plugin_1.dll">;
     Plugin<string> plugin2 = new Plugin<"Plugin_2.dll">;

    In (A), I haven't found a way to use a non-const string as DllImport filename.
    In (B), I know the syntax isn't correct. But is there a way to use generics to achieve something similar?


    Or isn't it even possible to do this? I guess someone else has experienced similar problems and found solutions for it. Is there a design pattern or best practise that I should be aware of?


    Any help appreciated,
    Thanks in advance.

    • Edited by Tyler70 Thursday, October 22, 2009 8:32 AM fixed minor typo
    Thursday, October 22, 2009 8:29 AM

Answers

  • Hello,

    An option is to write your class as managed class in C++\CLI (so it still will be easily accessible with .NET code). And within your class call LoadLibrary Win32 function. You can provide library name at runtime here.
    http://msdn.microsoft.com/en-us/library/ms684175%28VS.85%29.aspx
    Then having dll loaded you can call its methods (of course if you know signature).

    The drawback here is that you don't have marshalling provided by DllImport and would have to do marshalling by yourself.
    Vitaliy Liptchinsky http://dotnetframeworkplanet.blogspot.com/
    • Marked as answer by Tyler70 Thursday, October 22, 2009 11:33 AM
    Thursday, October 22, 2009 8:49 AM

  • Thanks for the quick reply. It really helped me to proceed, even though I didn't do exactly as you suggested.

    I ended up creating a native wrapper dll with the same signature as all any of the existing plugins, except that I can specify a plugin that the wrapper loads and simply redirect all calls to the plugin itself.

    Then my C# application loads the wrapper dll using DllImport("wrapperPlugin.dll"). In addition, the wrapper dll has a initialize method where the managed caller specifies the filename of the plugin dll.


    Kind regards

    • Proposed as answer by Vitaliy Liptchinsky Thursday, October 22, 2009 11:56 AM
    • Marked as answer by Tyler70 Monday, October 26, 2009 7:20 AM
    Thursday, October 22, 2009 11:33 AM

All replies

  • Hello,

    An option is to write your class as managed class in C++\CLI (so it still will be easily accessible with .NET code). And within your class call LoadLibrary Win32 function. You can provide library name at runtime here.
    http://msdn.microsoft.com/en-us/library/ms684175%28VS.85%29.aspx
    Then having dll loaded you can call its methods (of course if you know signature).

    The drawback here is that you don't have marshalling provided by DllImport and would have to do marshalling by yourself.
    Vitaliy Liptchinsky http://dotnetframeworkplanet.blogspot.com/
    • Marked as answer by Tyler70 Thursday, October 22, 2009 11:33 AM
    Thursday, October 22, 2009 8:49 AM

  • Thanks for the quick reply. It really helped me to proceed, even though I didn't do exactly as you suggested.

    I ended up creating a native wrapper dll with the same signature as all any of the existing plugins, except that I can specify a plugin that the wrapper loads and simply redirect all calls to the plugin itself.

    Then my C# application loads the wrapper dll using DllImport("wrapperPlugin.dll"). In addition, the wrapper dll has a initialize method where the managed caller specifies the filename of the plugin dll.


    Kind regards

    • Proposed as answer by Vitaliy Liptchinsky Thursday, October 22, 2009 11:56 AM
    • Marked as answer by Tyler70 Monday, October 26, 2009 7:20 AM
    Thursday, October 22, 2009 11:33 AM