Question

When dealing with plugin assemblies in their own subdirectories, there is the well-known problem that these assemblies fail to load once they try to load their respective dependencies from their subdirectories. A solution is to load the plugins in AppDomains which had their PrivateBinPath set in their AppDomainSetup object upon initialization. However, this causes other difficulties concerning marshalling/cross-AppDomain communication, in particular if the plugins are supposed to provide some GUI.

When security aspects have a lower priority (non-critical utility application, no severe problems upon crashes caused by faulty plugins), I’ve had the following idea: Upon application start-up, all plugin directories should be searched for, and a new AppDomain should be created that has those directories in its bin path. Then, the whole application and its GUI run in that new AppDomain, along with all plugins.

Under the given circumstances, are there any reasons to avoid that solution? Or are there maybe any reasons why that solution isn’t even feasible?

Answer 1

Taking in consideration your described scenario I don’t know of any issue associated with your proposal for a second domain. However, you may also investigate the possibility of handling the assembly loading failures on the initial domain by searching yourself through the addins sub-directories and loading the assembly from there using Assembly.LoadFrom.

Example of a possible setup for this, where the FindAssemblyByName would have to be implemented to search through all the possible locations:

static void Main(string[] args)
{
    AppDomain.CurrentDomain.AssemblyResolve += CurrentDomain_AssemblyResolve;

    // ...
}

static Assembly CurrentDomain_AssemblyResolve(
    object sender, 
    ResolveEventArgs e)
{
    var assemblyName = new AssemblyName(e.Name);

    string assemblyFilePath = FindAssemblyByName(assemblyName);

    if (string.IsNullOrEmpty(assemblyFilePath))
        return null;

    return Assembly.LoadFrom(assemblyFilePath);
}