Plug-in capable application architecture leads to version trouble

  • Thread starter Thread starter George
  • Start date Start date
G

George

I have a .NET 1.1 C# app (lets call it MyApp.exe) which is designed to
do some boring thing (not important now) but it can be extended with
plug-ins. These plug-ins are subclasses of a type (PlugInBase)
contained in a shared assembly (MySDK.dll). At startup, MyApp.exe
reads the registry for a list of plug-in assemblies to load from the
GAC. These assemblies are instanciated (using Assembly.Load) and
searched for types that subclass MySDK.PlugInBase. When found, these
types are instanciated with Activator used normally.
From its inception, it was my intention to have others (3rd parties)
Click to expand...
create the plugins. I expected them to develop their plugin by
referencing MySDK.dll and implementing their own subclasses of
PlugInBase. Then, to integrate their plugin into MyApp, they need to
install their assembly into the GAC and add a registry entry requesting

MyApp to load it by name.

My initial testing worked well. I created projects within my main
VS.NET solution that contained implementations of PlugInBase and were
installed into the GAC with a post-build event. Everything seemed to
be fine... until I tried to separate the plug-in projects from the main

solution. It became a versioning nightmare.


What I have missed is the simple fact that MySDK.dll is strongly named
and everytime I fix a bug and release a new version of it (example
1.0.0.0 to 1.0.0.1), all plug-ins must be recompiled using the new
version of MySDK.dll. This is impractical, since it would require
massive coordination with 3rd party authors - some of whom I may not
know.


The solution I seek would allow me to patch MyApp.exe and MySDK.dll,
without requiring a recompile of the 3rd party plug-ins. Can this be
done?


I have pondered this question and have some thoughts and questions?


Can an assembly load event be hooked which allows me to substitute the
new assembly?
Would a config file setting help?
Should I change my plug-in communication from inprocess to something
else (maybe .NET remoting)?
Is there something in .NET 2.0 which can help? I don't want to
upgrade, but will if necessary.
Should i consider an interface only approach - removing my
implementation from the MySDK assembly and thereby minimizing the
number of updates to the assembly?


I welcome all ideas and advice
 
Back
Top