Re: Plugins Design Question

Use interfaces.  Create a "Main" interface that has all of the methods /
properties declared.  Link COMMON to MainInterface.  At run-time, you can
enumerate through the various assemblies (using the Assembly.Get---Assembly
methods) to get to the MAIN.dll.

Just a few thoughts to get you working in the right direction.

R

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-WINFORMS@xxxxxxxxxxxxxxxxxxx] On Behalf Of JD
Sent: Friday, February 27, 2004 3:30 PM
To: DOTNET-WINFORMS@xxxxxxxxxxxxxxxxxxx
Subject: [DOTNET-WINFORMS] Plugins Design Question


In a Winforms app, I've currently got a 'plugin' architecture that
'discovers' available plugins at runtime and then uses dynamic assembly
loading to make them available within the "shell" application. In terms of
assemblies, this (in simplified terms) looks like:

launcher.exe <-- a nearly empty bootstrapper for the app common.dll <-- the
NON-visual portions of the architecture main.dll  <-- the visual UI stuff,
including the main MDI parent form pluginX.dll <-- an example plugin
assembly

Currently all is well with the pluginX project having only a reference to
the common.dll. This gives it access to the application object and all the
services it needs (data, security, configurations, etc).

I'm working on a new app-wide service now that has both non-visual
components and a UI component (a form). I'm trying to maintain the
separation between the common.dll and the main.dll, but the synapses aren't
firing in the right order today.

If I have the plugin (with it's reference to the non-visual COMMON) call the
non-visual component, then I will need that component to create the form.
This breaks my goal because it means that COMMON (the non-visual project)
has to know about MAIN (the project with the visual stuff). And when the day
comes that we want to use COMMON.DLL on a web project or with a different
winforms app, it gets ugly.

I could give the plugin a reference to MAIN.dll, in which case it could open
the form (from MAIN) and the form could create the non-visual component
(from COMMON). The downside here is that we've thus far avoided having any
reference to MAIN in the plugins. If we should need the plugins to work in a
different "plugin host" application, it gets ugly.

I *know* there's a simple solution pattern here, but darned if I can find it
on a Friday afternoon.

Any suggestions would be appreciated,

JD