Meeting assembly dependencies in a MEF environment

Question

I have an application in which I am employing MEF to dynamically load extension assemblies. One assembly is a domain layer, the second is a view. The domain assembly load and works as expected. The pseudo structure looks like this:

• Solution
  • Domain Project
  • View Project

The issue that I am having is that the view assembly contains 1..N user controls that are visual proxies for domain objects in the first assembly. This places a constraint on the view assembly in that it depends upon the domain layer assembly. e.g. from above, the View Project assembly depends upon the Domain Project assembly. I suspect that moving the visual proxies from the view project into the domain project would solve the problem, however, it would go against separation of concerns.

When calling the Assembly.LoadFile() method on the view assembly, I receive the typical FileNotFoundException. I believe this to be because the domain layer assembly loaded first lives outside of the root of where the application is running and therefore not within the probe path. What I was hoping for within this process would be that because the core assembly had already been loaded that the dependency that the view assembly has on it would have been satisfied. Unfortunately this was not the case.

The AppDomainSetup.PrivateBinPath is not an option for me. This would place constraints on extension developers to install within the file structure where the application has been installed which would lead to pollution and this is not something that we need or desire. I am aware of how much simpler that this task would be having a single Extensions directory under the installed application root.

What I would like to do is to be able to load assemblies and have their dependencies met by other assemblies that have already been loaded and added to an AggregateCatalog.

Does anyone have any thoughts, suggestions or advice that can help me achieve my goal?

Answer 1

Okay, the solution for me was to not use module initialization through assembly injection. While quite ingenious, it does not appear to get called at all for framework 4 when loading an assembly from C#. It may work under other circumstances.

The solution for me was to get back to basics and rely on the current AppDomain's AssemblyResolve event. First, while building a ComposablePartCatalog of my extensions, I stored my extension paths in a collection. When an assembly load failed, the AssemblyResolve event fires and I iterate over my collection of extension paths looking for the dependency of the extension.

This fits quite well with my goal of maintaining separation between an installed application and any installed extensions.