Questions on using/moving from standard System.Composition

[srkinyon]

Our system is currently using System.Composition for MEF and we'd like to add the caching feature using this package. What isn't clear is how to get this package to work with out existing setup. Here's some issues/questions:

1. We're using the AggregateCatalog that has both AssemblyCatalogs and a DirectoryCatalog. How do we use a DirectoryCatalog with the ComposableCatalog?

2. We use an ExportFactory with an ImportMany attribute to create many instances of an exported part. Can we continue to use the ExportFactory or is there another construct that replaces it in this package?

3. Is there more documentation on the caching? I assume the ExportProviderFactory.LoadDefault() loads from cache, what if things haven't been cached? Where is the actual cache located?

4. Is there an example project somewhere that has a typical System.Composition MEF scenario and how VS MEF works with it or in place of it?

Thanks!

[AArnott]

To start off, I'll call out that the caching feature is a proof of concept in its current form. I wouldn't recommend shipping an app that relies on it just yet. We are actively working on finishing that feature though, so I hope soon we can freely encourage people to try it out and ship with it.

To your questions:

1. In VS MEF we just have ComposableCatalog. You can add parts to an existing one and merge catalogs together. You can use the PartDiscovery-derived class to scan entire assemblies and add the resulting parts to a catalog, and you can loop over all the assemblies in a directory and do the same thing.
2. ExportFactory<T> works great in VS MEF. Having an [ImportMany] attribute on it I believe wouldn't be used to "create many instances of an exported part" however, since a single ExportFactory<T> does just that. Rather, if you have [ImportMany] on an List<ExportFactory<T>> what you get is one ExportFactory<T> for each unique export of T. You could use this collection of factories to create instances of many different parts.
3. Yes, LoadDefault() loads an existing cache. The way the AppHost package works is it leads your project to construct this cache at build-time. The idea is you ship the cache with your application so that it's always present. However this design doesn't leave your app extensible after you've built it. Our readme goes over this and how to write an extensible app if that's what you need. Visual Studio itself demonstrates that VS MEF can be used to create an extensible app with caching, but there's a great deal of cache handling code in VS itself that is not part of the VS MEF library. I hope we can bring more of that into the VS MEF library in the future.
4. I don't know of one off hand outside our own unit tests and documentation. So I just created one for you to look at.

[AArnott]

I wrote up some additional docs, including the topic of DirectoryCatalog, which you can review here.

[srkinyon]

Thanks for your quick responses and demos. I was able to put together a test project with all the ways we used System.Composition so we're on the way. I'm performance testing right now, so hopefully this will bump the speed up.
If you are interested when I'm done with testing I can post my test project which has your example code and the other elements we use, such as DirectoryCatalog, ImportMany, & ExportFactory.

[AArnott]

I'd love to hear the results of your effort and perf testing.
Without the cache, I expect your startup time to perhaps go down since VS MEF front-loads composition while MEFv2 you pay for it repeatedly in throughput perf. With the cache (which is getting closer every week) I expect VS MEF to be faster than MEFv1 and MEFv2 in (nearly?) every metric.