ContainerStartup()

{

  Module1.Startup();

  Module2.Startup();

  Module3.Startup();

}

 

Each module may or may not use DevForce as its data access mechanism (some are more enlightened than others).  No module knows about other modules.

 

We know we have a performance issue for discovery, so we believe we should use the SearchPatterns.Clear() then set the pattern (in each case the actual assembly) where the classes of interest reside.

 

So, the question is, how can we make this work, as each module will (possibly) access devforce as part of its startup processing, and therefore initiate the MEF composition machinery.  I am concerned that the CompositionHost will not allow for multiple initializations...?

 

or perhaps it just works by MEF magic?

 

Since the modules don't know about one another it makes setting really narrow SearchPatterns difficult, but if you can find some somewhat broad but not too broad pattern(s) that may help improve the performance; for example, maybe all the assemblies you care about will start with your company or application name.  In the 6.1.0 release we'll also be adding IgnorePatterns, which let you customize the patterns for what should be excluded from discovery. 

 

We'll look at opening a feature request to support "recomposition" for non-Silverlight applications. 

 

There's more information about discovery on the Resource Center too - http://drc.ideablade.com/xwiki/bin/view/Documentation/discovery - http://drc.ideablade.com/xwiki/bin/view/Documentation/discovery .

 

 

 

 

 

It seems that the problem is caused by having lots and lots of assemblies along with a discovery model (any assembly might have required stuff in it) resulting in a scalability problem.  Stepping back, I think a registration pattern would be more appropriate.  The containing code (and the devforce "run time") don't know which assemblies/classes might need their services;  asking each one the question is time consuming.

 

Each assembly/module certainly knows it needs such services, and could register explicitly with a ModuleX.PleaseRegisterMeForYourServices() style call when it gets its chance to "startup".  Obviously this changes the implementation requirements on the devforce internals for initializing classes/models etc. to be lazy and able to aggregate more than once over time.

 

Whether this fits into MEF in general or your offer to consider a new feature in WPF for recomposition support I don't know.... hence this note to explore the problem further.  What I think we need in an ideal world is a PleaseRegisterMe call.

 

 

 

There are a couple of things going on with the CompositionHost - some are DevForce-required and some are plain MEF.  DevForce only needs to know about your entity models and interface implementations, while any non-DevForce imports and exports are handled only by the underlying MEF container.  For any non-DevForce content you can always access the container and add content directly to it.  DevForce won't be aware of that new content and won't update its metadata and other information it tracks, but MEF will register everything for you.