.net dll plugins called from native application RRS feed

  • Question

  • Hi there,

    I have the following setup:

    - Native application in folder "App"

    - Plugins folder "App/plugins"

    - For each plugin a new folder "App/plugins/plugin1"

    - In the "plugin1" folder I have a mixed dll (c++/cli) which references a bunch of .net dlls in the same folder

    Now the Native application uses LoadLibrary to load the mixed dll, but the runtime fails to find the .net dlls.

    From what I understand some methods to solve this would be .config files <probe>, creation of a new app domain, etc.

    I don't see how this could help me in this case since the starting app is a native app that loads a mixed dll (which references other .net dlls at design time ). Somehow I would need to set this new app domain in the native application before the mixed dll is even loaded.


    Are there any other ways of accomplishing this that I'm unaware of?

    Thank you in advance.

    Monday, November 29, 2010 6:07 PM

All replies




    Thank you for your question. We're doing research on this issue. It might take some time before we get back to you.

    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Wednesday, December 1, 2010 9:22 AM
  • Hi,

    Are you still having this issue? Did you find resolve? What was it?

    bill boyce
    Thursday, January 6, 2011 10:05 PM
  • I hacked something to make it work.

    1. Created the main DLL that plugs into the native application and enumerates plugin DLLs in subfolders (or you code your native app to do the enumeration )

    2. For each enumerated DLL (mixed, CLI\C++) : a method named by convetion IInterfaceObject GetObject() returns an object that implements the IInterfaceObject with which the mainDLL interracts.

    3. The mixed DLL must not reference any custom .net dll in its project settings or we crash here

    4. The class that implements IInterfaceObject will be reffered to as InterfaceObjectClass from now on

    5. InterfaceObjectClass contains a gcroot<IDotNETInterfaceObject> object

    6. In the constructor of InterfaceObjectClass we create an app domain and use System::ReflectionAssembly::Load to load our .net dll (this dll can now reference other .net dlls ) and retrieve an object that implements IDotNETInterfaceObject and store it

    7. Now the InterfaceObjectClass will act as a proxy to all calls made by the native DLL to the .net object

    You will need to have another proxy class if you want to do callbacks from the .net object into the native dll

    Drawbacks: either IDotNetInterfaceObject needs to be defined in the .net dll AND CLI dll (and kept in sync) or if you put it in one dll, that DLL needs to reside in the native app folder or the GAC to be shared by multiple plugin dlls.

    I'll try to make a tutorial with code and sample project on how I've managed to do this and post back here.

    Monday, January 10, 2011 3:05 PM