MEF - Plugins and their referenced assemblies

2
votes

For an application i am building we use MEF to create the plugin system. Each Plugin is build with it's own dependencies (references) and in the end copied into a designated folder which the application is aware off and looks for plugins. The copying is done with a post-build script btw.

The problem is that we have separate plugins that may reference different versions of the same assembly. For this we had the idea that we should make every plugin create it's own folder within the plugin folder as to keep the assemblies from overriding each other. But then we get exceptions because the AppDomain doesn't know were to look for the references needed by the plugins. We did find that we can provide the paths with probing. But that would mean having to register every plugin in the app.config. And we were looking to do this in a more generic way.

The application is not a web application. It's a console application that will serve as a server and we call this the shell. The assemblies are not known to the shell, but only to the plugins of the shell. These plugin's are not known to the shell either but rather discovered by MEF. The only thing gluing the shell and the plugins together are interfaces.

I'm really stuck on this item and would appreciate any help i can get on the matter. This is rather a .Net framework question than a MEF one, but i thought i'd give a sketch of the situation.

1
.netassembliesapp-configmefappdomain
Take a look at the BuildManager.AddReferencedAssembly method and the PreApplicationStartMethodAttribute. With its help, you can add assemblies to the application's set of referenced assemblies early in the lifecycle. I'm not sure if they can help you with different plugins referencing different versions of a same assembly. - Ilija Dimov
Thanks Ilija for your reply. The application is not a web application. It's a console application that will serve as a server and we call this the shell. The assemblies are not known to the shell, but only to the plugins of the shell. These plugin's are not known to the shell either but rather discovered by MEF. The only thing gluing the shell and the plugins together are interfaces. - Bosken85

1 Answers

1
votes

An alternative to using probing paths would be to use the AppDomain.AssemblyResolve event. Whenever .NET is unable to load an assembly, it will raise this event which will allow you to locate and load the assembly yourself. It might not be the cleanest solution, but it does give you the flexibility of putting your assemblies in whatever structure that suites you.