Plugin System Recommendations

[James Hancock]

Here's the scenario.

Right now I'm using a single app domain and loading my plugins into it. This
works ok, but it makes me uneasy and it also means that anyone building
plugins have to use the exact same version of my dependancies (DevExpress)
that all of the plugin stuff is built on.

What I would like to do is use an AppDomain to alieviate this issue and
allow the new appdomain to load in separate versions of these dlls as needed
for the plugin.

The problem is, that when I use any of the samples online and start doing
stuff with secondary app domains I need up with all kinds of errors.

Basically the system is based on Interfaces, so the plugin will impliment a
class with the interface on it.

I want to be able to call from my primary app domain, a function in my
plugin manager that will return the class with the interface as the
interface type so that I can make calls to functions on it as per the
interface.

I.e. I need to be able to make a call that will load up a new WinForm and
then go and do something with the new winform.

Every time I do this with Activator.CreateInstance() in the secondary
domain, I get an error in the primary domain that it can't find the
assembly. Once I even got to say that I needed to make the class
serializable on the plugin. So I did that, and then it gave me a
serialization error the next time.

I know that what you're supposed to do is make calls against the "stub"
class that is in the secondary domain, but I don't think that that is really
feesible, because I'd have to have functions for each function that is
defined in each of my interfaces would I not??

Any advice would be greatly appreciated!

Thanks,
James Hancock

 

[James Hancock]

Hello, James!

JH> Every time I do this with Activator.CreateInstance() in the secondary
JH> domain, I get an error in the primary domain that it can't find the
JH> assembly. Once I even got to say that I needed to make the class
JH> serializable on the plugin. So I did that, and then it gave me a
JH> serialization error the next time.

You can derive your plugin class from MarsharByRefObject, then class will
not be serialized.
To avoid FileNotFound exception while looking for assembly you can put
that assembly into GAC,
(this will make sense since you mentioned that there can be multiple
versions of the same plugin).

The GAC isn't an option for me unfortunately. I need this to be
self-contained drag and drop. Everything for the app goes in one directory
and the plugins go in a sub directory.

The stub object is MarshalByRefObject. That was the odd part about the
error....

JH> I know that what you're supposed to do is make calls against the
"stub"
JH> class that is in the secondary domain,

The stub is in the same domain where the caller is.

Right, that's the problem.

JH> but I don't think that that is
JH> really feesible, because I'd have to have functions for each function
JH> that is defined in each of my interfaces would I not??

Can you give more info about this issue?

OK, this is for a GUI plugin. That is, one of the functions will often
return a WinForm that is then manipulated and added to the MDI parent and
results are retrieved from. Thus the WinForm needs to be in the same app
domain no?

Basically I want to have my cake (separate app domain) and eat it too, work
directly with objects returned. My theory is that I should be able to work
the same way I do in remoting. That is, because both computers share the
same stub, I can move stuff around between the two. I'm hoping to do the
same here. In both the host application and the plugin they will share the
DLL that has the interfaces and the defintion for the window types
(inherited versions of Winfroms). So I should (in theory) be able to pass
them back and forth no?

 

[James Hancock]

Vadym,

Thanks for the clarification! I really appreciate the help. You just saved
me hours of banging my head against the wall

James Hancock