Doing the Right Thing when designing plugin architectures

[Rune Jacobsen]

Hello all,

I mailed our common hero and fellow newsgroupian Jon Skeet a question
regarding his article on plugins at
http://www.yoda.arachsys.com/csharp/plugin.html, and he suggested that I
should post here. I was afraid to spam the group further with my silly
questions, but I agree with his sentiment that this might benefit
others, so here we are.

My question regards the proper way to build the plugin projects. My host
application is a typical winforms application; I want to create an
interface that I can then code plugins towards for all the usual
benefits. That's fine. I figure I will make some hooks for the plugins
to add custom menus to the program at certain points, add new windows,
present their config interface etc.

The way I figure it, I need two interfaces; One for the plugin itself.
It needs to implement some initialization method, a deinit-method, a
showconfig-method and some other stuff. The host interface, on the other
hand, would present the plugin with common data and events to subscribe
to. Hopefully this is relatively simple.

My question (at long last) is how I should practically approach this. Is
the simplest thing to make several C# projects like these?

1) Host Application
2) Interface only class library
3) Plugin A
4) Plugin B

Or is that a braindead way of doing it?

Also, lets say I have a directory structure like this;

$PROGRAMFILES\MyApp\
MyApp.exe
somedll.dll
plugininterface.dll
Plugins\
plugina.dll
pluginb.dll

Will I also need to stick the plugininterface.dll in the Plugins folder?
Or will I need to register the dll somehow?

As you can see, my question isn't so much about the actual coding of the
plugins/interface/host application (I've got plenty of information from
Jon's article and google on that), it's about organizing the projects
and/or solutions.

It is easy to find plenty of information on how Interfaces work in C#,
why they are the Correct Way etc., but it's been hard to find proper
information on how to organize this neatly into projects. In the future,
maybe an external developer wants to write a plugin for my application -
in that case, I don't really want to give him access to any source code
or logic beyond the plugin/host interfaces, so a nice separation of
these things would be awesome.

I should also mention that I am still using Visual Studio 2003 and .net 1.1.

If anyone could shed any light on this, I would be most grateful.

Thank you very much for your help in advance!

Best regards,

Rune Jacobsen

[Jon Skeet [C# MVP]]

Rune Jacobsen <rune.jacobsen@no_spam.broadpark.no> wrote:

<snip>

My question (at long last) is how I should practically approach this. Is
the simplest thing to make several C# projects like these?

1) Host Application
2) Interface only class library
3) Plugin A
4) Plugin B

Or is that a braindead way of doing it?
No, that's a great way of doing it.
Also, lets say I have a directory structure like this;

$PROGRAMFILES\MyApp\
MyApp.exe
somedll.dll
plugininterface.dll
Plugins\
plugina.dll
pluginb.dll

Will I also need to stick the plugininterface.dll in the Plugins folder?
Nope.
Or will I need to register the dll somehow?

Nope.

The above directory structure looks fine to me, and works with the
sample code I've used in the article.

My one concern is that I use Assembly.LoadFrom, and I'm frankly not
terribly knowledgeable about the ramifications of all the different
types of Assembly.Load calls.

For instance, if a plugin needs another library, I *think* it would
have to go in your main directory unless you have a private path to the
plugins directory. For simple situations, of course, this wouldn't be
an issue...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Rune Jacobsen]

Hi Jon, and thanks again for your insight!

Jon Skeet [C# MVP] wrote:

Rune Jacobsen <rune.jacobsen@no_spam.broadpark.no> wrote:
<snip>
(Left for future discussion)

$PROGRAMFILES\MyApp\
MyApp.exe
somedll.dll
plugininterface.dll
Plugins\
plugina.dll
pluginb.dll

My one concern is that I use Assembly.LoadFrom, and I'm frankly not
terribly knowledgeable about the ramifications of all the different
types of Assembly.Load calls.
I will probably bump into some errors and learn a lot from it, but I
will keep in mind that there are things to be aware of here!
For instance, if a plugin needs another library, I *think* it would
have to go in your main directory unless you have a private path to the
plugins directory. For simple situations, of course, this wouldn't be
an issue...

Okey, I see. So basically, because MyApp.exe is the one that loads the
plugin assembly, everything will be okey since the plugininterface.dll
is in the same directory.

Now, if someone suddenly writes the super-happy-advanced-magic
SuperPlugin.dll that needs some config files, some data files etc., I
thought that perhaps a good way to handle this would be to stick
SuperPlugin.dll in the Plugins\ folder, and then the installer for this
plugin (if separate) should make a SuperPlugin\ folder in the Plugins
folder to store its files in. The host application could then have some
method like GetPluginDir() which would probably return
$PROGRAMFILES\MyApp\Plugins\SuperPlugin\ - which of course everyone
would need to use since the evil developer of the host app (me) could
suddenly decide to change things to test for lazy plugin devs...

Am I on Fantasy Island here, or does this sound like a healthy way to
manage a small project that could potentially grow large eventually?

Again, many thanks for the help in understanding the thinking behind
doing this properly!

Best regards,

Rune

[Jon Skeet [C# MVP]]

Rune Jacobsen <rune.jacobsen@no_spam.broadpark.no> wrote:

<snip>

For instance, if a plugin needs another library, I *think* it would
have to go in your main directory unless you have a private path to the
plugins directory. For simple situations, of course, this wouldn't be
an issue...
Okey, I see. So basically, because MyApp.exe is the one that loads the
plugin assembly, everything will be okey since the plugininterface.dll
is in the same directory.

Now, if someone suddenly writes the super-happy-advanced-magic
SuperPlugin.dll that needs some config files, some data files etc., I
thought that perhaps a good way to handle this would be to stick
SuperPlugin.dll in the Plugins\ folder, and then the installer for this
plugin (if separate) should make a SuperPlugin\ folder in the Plugins
folder to store its files in. The host application could then have some
method like GetPluginDir() which would probably return
$PROGRAMFILES\MyApp\Plugins\SuperPlugin\ - which of course everyone
would need to use since the evil developer of the host app (me) could
suddenly decide to change things to test for lazy plugin devs...

Something like that, yes. You may well just be able to get away with
adding a private path to the plugins directory, but I'm not going to
say for sure without having tried it :)
Am I on Fantasy Island here, or does this sound like a healthy way to
manage a small project that could potentially grow large eventually?
It sounds reasonable to me. Don't make it more complicated than it
needs to be just yet - the simple separation between plugins and the
host sounds fine for the moment.
Again, many thanks for the help in understanding the thinking behind
doing this properly!

No problem.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too