Loading .dll into separate application domain (MEF)

Question

I'm trying to load an assembly into a separate applicaiton domain. I don't want to create any instances or execute the assembly. So I'm not using CreateInstanceAndUnwrap method. I just want to load the dll file (not creating any types from it etc..)

        var cat = new AggregateCatalog();
        pluginApplicationDomain = AppDomain.CreateDomain("pluginApplicationDomain", AppDomain.CurrentDomain.Evidence,
        appDomainInfo);

        cat.Catalogs.Add(new AssemblyCatalog(pluginApplicationDomain.Load(File.ReadAllBytes(plugin))));

and plugin is a relative path to the dll file.

../../Extensions/Plugins\MyAssembly.dll

This throws 'System.IO.FileNotFoundException' The path is correct, and if I do Assembly.LoadFrom(plugin), it doesn't throw any exceptions, so I'm guessing it's not the path that's incorrect.

Other solutions all used CreateInstanceAndUnwrap, but what if the assembly and its types are black box to me? I know it impements one interface and that's it?

Load dll into another domain exception

would this work? However my method's signature doesn't match that one of CrossAppDomainDelegate

What are you trying to achieve, i mean, why do you need to load the assembly to separate domain? — igorushi
Since it's a plugin, I want to have it loaded in a separate domain because if the plugin crashes, the main application won't, because it's in a different domain. — Mefhisto1

igorushi igorushi · Accepted Answer · 2015-02-16T10:31:08

MEF is more about extensibility and it seems like you actually looking for [MAF]1. Check out this SO question. From my personal experience if your plugins going to invoke some native code (interact with hardware for example) AppDomains will not prevent crashes. It's safer to host such plugins in separate processes.

Loading .dll into separate application domain (MEF)

1 Answers