AppDomains workaround for plugins

Question

When working with plugin assemblies in their own subdirectories, there is a known problem that these assemblies cannot load when they try to load their respective dependencies from their subdirectories. The solution is to load plugins in AppDomains that have their PrivateBinPath installed in their AppDomainSetup object during initialization. However, this causes other difficulties related to the transfer / cross-connection to the AppDomain, in particular if plugins should provide some GUI.

When security aspects have a lower priority (non-critical utility application, no serious problems during failures caused by erroneous plugins), I had the following idea: when starting the application, I need to look for all the plugin directories and a new AppDomain must be created that has these directories in its path to bin. Then the entire application and its graphical interface are launched in the new AppDomain along with all the plugins.

Under the circumstances, are there any reasons to avoid this decision? Or maybe there are some reasons why this decision is not even possible?

Answer 1

Considering your described scenario, I do not know of any problems associated with your proposal for the second domain. However, you can also explore the possibility of handling assembly load failures in the source domain by searching through the addins subdirectories and loading the assembly using Assembly.LoadFrom .

An example of a possible setting for this is where FindAssemblyByName should be implemented to search all 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); }