This is a lengthy post; please bear with me...
This will be a large system with dozens of plugins. In addition to plugins
developed internally there will be 3rd parties that will write their own and
integrate them into our application. I will be managing the identification
and loading of these plugins. In addition, there are a number of assemblies
that plugins will reference, some shared, and others private.
There are a couple of approaches I am considering.
It is expected that all plugins will need to be registered so that the app
does not blindly load up
all assemblies searching for plugins to load.
FIRST OPTION - separate directories
The expected directory layout is like this...
BaseDirectory (application)
PluginManifest. xml (info on which ones to load)
|
|
-- Common (shared.dll, all versions forced to latest)
|
|
-- PlugIn1 directory (Plugin1.dll, private1.dll, v1.0)
|
|
-- PlugIn2 directory (Plugin2.dll, private1.dll, v1.1)
|
|
-- PlugIn3 directory (Plugin3.dll, private1.dll, v1.2)
All assemblies that share types are to be relocated to the common
directory. This occurs when the
assembly is installed. This involves determining if an assembly is intended
to be shared - this
implies that the assembly is exporting a type that the consumer of that
assembly (i.e. the plugin) is
also exporting or importing.
All shared assemblies will have binding redirects so that all other
assemblies will all be pointing
at the same one.
All assemblies that are intended to be private will remain in the
subdirectory of the plugin. A codebase hint
for each assembly to be loaded will be placed into the app.config file so
that the assembly lives in the fusion load context.
ALTERNATIVE:
Put all assemblies into the same directory and enforce a naming convention
like this...
<namespace>.<as mName>.<version >.dll
This is intended to result in all assemblies having a unique name; the
name to include the assembly
version number.
No binding redirects to be done, nor will codebase hints be used, unless
there is a common assembly that
all others must share. This will be identified manually and a binding
redirect put into the app.config file.
The layout looks like this...
BaseDirectory
PluginManifest. xml (info on which ones to load)
|
shared.v1.0.dll , shared.v1.1.dll , shared.v1.2.dll ,
|
|
PlugIn1.dll
PlugIn2.dll
PlugIn3.dll
private1.v1.0.d ll
private1.v1.1.d ll
private1.v1.2.d ll
PROS and CONS:
Separate directories.
PROS
Prevents clutter. Makes it easier to separate "system" *(i.e. our)
assemblies from addins, 3rd parties,
etc.
Ensures that all private assemblies remain that way as they are isolated
by directories.
There is no global naming scheme we need to maintain or enforce.
Each plugin can have separate associated data files. Can use its own
subdirectories.
No naming conflicts.
CONS
Much more overhead in managing the system. I have to write a fusion-like
layer to handle all
the locations that assemblies can be in, the binding redirects, etc.
All plugins need to be analyzed for common items during the registration
process.
One directory
PROS:
Has the advantage of simplicity. Easy to locate and load assemblies.
No fusion-like layer to manage the assemblies is needed.
CONS
Requires a global naming scheme that everyone must adhere to.
Each plugin may be using a different version of an assembly and there is
no way to tell which one
is using what since they are all located in the same directory.
Identifying conflicts will be a nightmare.
If an assembly accidentally exports a type that is supposed to be private
will result in an error (typecase)
that will be very hard to troubleshoot.
Will be hard to "know" what assemblies are actually used and needed.
Clutters the directory.
If a plugin uses a data file may result in a name conflict with another
plugin.
So, anyone have any comments? Which method would be best? What other methods
are there that I did not mention?
Thanks,
David Levine
