In the DiscoverPluginAssembliesHelper() method within Cropper.Core\Plugins.cs , Cropper loads assemblies with Assembly.LoadFile().
This method does not use the ApplicationBase or the PrivateBinPath. What this means in practice is that if any plugin assembly depends on another third-party assembly that is not in the GAC, the plugin will not be successfully loaded. This leads to an unnecessary
limitation in packaging flexibility with respect to plugins. In particular, in the cropperplugins project, there is some code that I'd like to factor out into a common DLL., and then allow the specific plugin DLLs to depend on that common DLL. this isn't possible,
the way Cropper works today.
The fix would be to replace LoadFile with LoadFrom.
An alternate fix would be to keep LoadFile, but at the top of the DiscoverPluginAssembliesHelper() method, subscribe to the AssemblyResolve event, like so:
AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(Resolver);
...where the resolver looks like this:
static System.Reflection.Assembly Resolver(object sender, ResolveEventArgs args)
var a1 = System.Reflection.Assembly.GetExecutingAssembly();
throw new Exception("GetExecutingAssembly returns null.");
string tokens = args.Name.Split(',');
if (!tokens.Equals("CropperPlugins.Common")) return null;
var pluginPath = System.IO.Path.GetDirectoryName(a1.Location);
// map simple name to DLL
var dllName = tokens + ".dll";
var commonLocation = Path.Combine
(Path.Combine(pluginPath, "plugins"), dllName);
One feature in particular that this enables within plugins is plugin chaining. Within the common DLL, I could define a well-known interface, and a plugin could look at other plugins for that interface, and chain to them if they support that interface. Today
this is not possible because it's not possible to create a common DLL that can be loaded by any plugin.
Well, it is
possible, if I put the common DLL into the Cropper install directory, rather than in the plugins directory. But that seems wrong.