Extensible App API

[Mike Hildner]

If you had an app that loaded plugins, what's the best way to allow the plugins to talk to the container?

I'm guessing kinda the reverse of the container loading the plugins. Define another interface and use that. Or maybe public methods that the container somehow exposes.

In general, how do you go about this?

TIA,
Mike

[Edneeis]

Maybe this will give you some ideas:
http://www.edneeis.com/example.aspx?ID=1

If not there should be other examples floating about the net. You could also take a dive into plugins for MS Office and see the model it uses. Generally speaking a plugin must reference something to get its Interface or Base class, then why not just pass an Application object or whatever is needed back to the plugin by calling one of its methods at startup.

[Mike Hildner]

Wow, cool, that gave me some things to think/read/code about. Once again, thanks.

then why not just pass an Application object or whatever is needed back to the plugin by calling one of its methods at startup

When I've needed to do a similar thing (not with plugins), I have done a similar thing. It's quick and effective. For some reason, I think this is not the "proper" way to do things, even though I do it.

On a high level, shouldn't it be best to have the "master" expose it's API rather than pass out an object of yourself?

[Edneeis]

Not really because its actually the other way around. The application is the one calling the plugin, the plugin is not calling the application, its just written to anticipate such. The API would really be the plugin structure or the plugin structure and the exposed 'application' object. This is essentially the model Office uses so I figure its ok.

[Lunatic3]

Edneeis: That sample is very good and I know it is not supposed to be a full featured program, but it has some minor problems, ofcourse not related to the concept of plug-ins, but I really don't like to see them in your applications. First: After loading a plug-in if you try to load another then even cancelling the operation will load the previous plug-in again, and second: If you try to load PluginEx.Shared.dll then obviously nothing will be loaded but you can not load PluginEx.dll afterwards, and third is the link in About form that does not work and .NET which is .NEt

[Edneeis]

Thanks I noticed the one about cancelling, well at least that it still loads anyway. I didn't know of the others, thanks for reporting them. In fact I think I'll fix them right now.


Hmmm it seems that you there is some kind of bug in reflection or the IsSubclassOf method of the Type object. The reason you can't load the plugin after attempting to load the Shared dll is because it no longer says its a subclass of PluginBase, even though it is. Even though the very same code runs correctly before attempting to load the Shared dll.