Thank you for reporting this issue.
There was two drivers around my decision to use MEF internally with StatLight.
- I needed to auto-discover a “part” by scanning the StatLight xap and looking for “ITestRunnerHost”. (This is to support different “runners” & which ever assembly was in the xap would be the one used.)
- I hadn’t had the opportunity to play around with MEF (yet) and the above case seemed a good fit to start my intro.
I agree that StatLight shouldn’t limit a testing solution from using MEF. Unfortunately I do think there are some scenarios that it will limit (at the moment).
Here are some bullet points I have - so far:
1. MEF - can be used with StatLight - the following link displays test case that uses MEF - that does work with StatLight. http://codepaste.net/72oyep I understand there are many different scenarios that
MEF supports and that I haven't thought of regarding how StatLight will affect it's usage (or lack of).
2. While spiking test in 1. above - I have a feeling that one of your issues might reside in the use of a DeploymentCatalog (Are you using a DeploymentCatalog?). As the xap under test is not actually the _host_ xap. StatLight is the host which dynamically
loads the xap under test's assemblies (one at a time). So when you create a CompositionContainer with a DeploymentCatalog - it won't find your exports, as they are not part of the original host xap. This is why I used the AssemblyCatalog in the above example.
3. I do agree that StatLight should probably _not_ be using global MEF container (through use of the CompositionHost). StatLight's usage of MEF is so isolated, that I have no need to be using the global instance. (If you'd like try changing
StatLight's App.xaml.cs MEF usage to create an isolated container and go from there. (Let me know if this helps with your problem)
One possible solution (so you could use the DeploymentCatalog), and one I've debated for a while now (for other reasons). Instead of StatLight being the host xap, and dynamically loading other the SUT xaps. I've toyed with the idea of StatLight injecting
itself into the xap under test (on the fly).
This would require.
- Injecting StatLight and all of StatLight's dependencies into the xap under test.
- Re-writing the xap under test's AppManifest - replacing the "startup" node with StatLight's startup App class.
I think there quite a few un-forseen gotchyas with this solution, however would resolve several known issues. Such as depending on other files with in the SUT's xap (xml, config, etc). StatLight currently has a hack to copy the WCF config file (if it exists
in the SUT xap) over to StatLight's xap on the fly to support specific usage of ServiceReferences.ClientConfig. (You can it's usage in the function RewriteXapWithSpecialFiles in http://github.com/staxmanade/StatLight/blob/master/src/StatLight.Core/Configuration/StatLightConfigurationFactory.cs)