A possible way to workaround your scenario would be inheriting from the
DirectoryModuleCatalog and overriding the InnerLoad method to use a custom
ModuleInfoLoader (the default one is private and most of its methods are internal so it cannot be extended). In the
LoadAssemblies method of your custom loader you would add a catch block for this kind of exception:
public void LoadAssemblies(IEnumerable<string> assemblies)
foreach (string assemblyPath in assemblies)
// Continue loading assemblies even if an assembly can not be loaded in the new AppDomain
//Your code here
This approach will still provide the automatic capabilities of deploying new modules by creating the assembly and does not require any configuration.
Another possible approach if you want explicit control about the assemblies to load could be
using a configuration file to populate the catalog. This is probably something that you might not be inclined to do, as you probably selected the
DirectoryCatalog approach to avoid having to configure any files, but it avoids having to create the extra classes.
This issue is registered in the Issue Tracker so you might want to vote for it and the team might take the suggestion into account for a future version.
Please let me know if this helps.