Plugin assembles best practices

From: David Levine (noSpam12dlevineNNTP2_at_wi.rr.com)
Date: 03/21/05 

Date: Mon, 21 Mar 2005 07:11:23 -0600

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>.<asmName>.<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.dll
 private1.v1.1.dll
 private1.v1.2.dll

 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

Relevant Pages

  • Re: C# DLL-plugin references
    ... The plugins load, and I can invoke methods through reflection until ... The only sollution I could find so far, is to manually add references ... Is there a way, without using the GAC, to reference these assemblies ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Appending to CurrentDomain private path using AppDomainSetup
    ... Do the assemblies in these private paths have unique dependent ... Plugins may have private assemblies that should be kept private (i.e. they ... to add a plugin locally on the client without adding it to the central ...
    (microsoft.public.dotnet.framework.clr)
  • Plugin assembles best practices
    ... This will be a large system with dozens of plugins. ... there are a number of assemblies ... all assemblies searching for plugins to load. ... There is no global naming scheme we need to maintain or enforce. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Reflection - Need advice
    ... I used reflection recently when I had to send a text-based command to objects implementing ISignalTarget. ... As a consequence you are able to read those contents yourself, and also execute methods etc too. ... If you have assemblies in a "Plugins" folder of your app that you want loaded dynamically, maybe because other people are allowed to write their own. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Checking for implementation of an interface
    ... > I have an application that accepts plugins. ... > checking the assemblies in the plugins folder to see if they implement ... If I load each assembly and check it, ... > interface once its loaded into the separate appdomain. ...
    (microsoft.public.dotnet.framework)
Loading