Plug-in architecture leads to version problems.

[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.PlugInBas e. When found, these
types are instanciated with Activator used normally.

From its inception, it was my intention to have others (3rd parties)

create the plugins. I xpected 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

[Chris Dunaway]

Instead of using a base class that your plug-in authors must inherit
from, use an interface instead. The plug-in authors can create classes
that implement the interface. You can still use the same method for
detecting and loading the plug-ins, but when you fix a bug, it will not
affect the plug-ins because the interface will not have changed. The
only time the plug-ins will be affected will be if the interface itself
changes which should be rare or not at all.

[Alan Pretre]

"Chris Dunaway" <du******@gmail .com> wrote in message
news:11******** **************@ o13g2000cwo.goo glegroups.com.. .

Instead of using a base class that your plug-in authors must inherit
from, use an interface instead. The plug-in authors can create classes
that implement the interface. You can still use the same method for
detecting and loading the plug-ins, but when you fix a bug, it will not
affect the plug-ins because the interface will not have changed. The
only time the plug-ins will be affected will be if the interface itself
changes which should be rare or not at all.

To further add to Chris's post, I would also say to define the interface in
a separate DLL so that it is distributable to your 3rd parties.

Also, some may disagree, but I think it's a good idea to put a version
number in the interface name in this situation. For example, IFoo_v1. That
way any given assembly could support multiple versions of the interface and
keep them straight. Taking it one step further, you could define IFoo_Base
and derive IFoo_v1 and IFoo_v2, etc. from IFoo_Base if there is some common
base functionality to be supported.

-- Alan