Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I'm very new to MEF still, but I wanted to add more to this discussion because I continually go through hell when trying to figure out why things don't work the way I expect them to.</p> <p>First of all, when you're working with MEF, I recommend adding System.ComponentModel.Composition to your solution, rather than just adding references to the assemblies. Although debugging issues in MEF feels like a recursive nightmare, it's absolutely inevitable and vital when you can't figure out what's going wrong.</p> <p>This leads me to my next point, which is to never, ever forget that MEF doesn't know about what you don't tell it, or <em>if you don't tell it properly</em>. For example, my alpha application was working great with MEF -- I had it compose parts in the main GUI, and all of the assemblies that got loaded by the container (which were dependencies of the main app) exported the necessary interfaces. Things worked out well and I was able to get MEF to resolve instances when and where I wanted it to.</p> <p>However, I just started working on the next version; some plugins loaded (those that exported an interface, but had no import requirements), while others didn't (those that did need imports). This time I composed parts in my ApplianceManager class, which is in charge of loading plugins, but the plugins needed to resolve imports from other classes in the application (in my case, the Model). I figured this should automatically happen, especially since I can see in the Catalog construction that those assemblies were detected... but I still can't get it to work... which brings me back to my first point -- add the source code, and not the assemblies alone. Debugging this is nearly driving me insane, but I'll eventually figure it out after a lot of diligent stepping through MEF code. :)</p> <p>I'd like to see someone post an answer to this question that talks about architectures that facilitate easy MEF integration. The answer regarding toolbar menus and such is really good, but I would like to see something that talks about things that reside entirely on the Model side of MVVM. Like how plugin managers, databases, plugins, and shared libraries should be arranged. I am still trying to figure out why I had a reasonably okay time getting my first MEF app to work, but after getting more "experience" with it, I cannot get my new app to work 100%.</p> <p><strong>UPDATE 2010-06-09</strong></p> <p>I'd like to add another possible practice for helping you navigate through the MEF shrubbery. Today, I needed to do a sanity check on that project that I "just couldn't figure out", so I whipped up a simple, unconventional UML class diagram where I used dependencies to mark Imports and Exports. Here's what I found, which made the issue very clear.</p> <p>Working application: <img src="https://farm5.static.flickr.com/4068/4686233547_3fe212def9_o.png" alt="alt text"></p> <p>Non-working application: <img src="https://farm5.static.flickr.com/4063/4686866750_6d3f559f88_o.png" alt="alt text"></p> <p>Isn't that stupid? The Model wasn't loaded, and it was on an island all by itself. I <em>believe</em> this is why my MEF-based dependencies aren't getting resolved (if anyone can corret me if I am wrong here, I would appreciate it, though!)</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload