Using MEF internally in Statlight was a bad idea

Jun 30, 2010 at 8:55 AM
Edited Jun 30, 2010 at 1:32 PM

Hi,

I have a lot of trouble with Statlight because it also uses MEF as same as my system under test (SUT) does. This screws up the SUT because there can be only one MEF container running at the same time. I tried to circumvent this by patching Statlight so it exposes its container in such a way that the SUT can access it. I also extended the LoadedXapData.cs in that way that the XAP assemblies are added to the MEF container, too, if possible. Ok , finally I'd had a container containing a mix of Statlight and SUT assemblies. Fine. Some tests worked then. But with writing additional tests in a MEF based solution one requirement is going to emerge quickly: Enable customization of the MEF container during tests to isolate the SUT better. But there's the catch. Rewriting the container for isolating the SUT can screw up Statlight's dependency on MEF easily, too *sigh*.

The limitation inside MEF supporting a single container only better should have lead into a design decision avoiding any dependency in Statlight onto MEF completely. I don't know the decision process why Statlight has needed MEF in the first place but it should be reconsidered. I think a testing tool shouldn't alter/restrict the SUT environment in such a way. I don't think my solution is the first and last one which is going to use MEF.

Best regards,
Thomas

 

Coordinator
Jun 30, 2010 at 4:15 PM

Thank you for reporting this issue.

There was two drivers around my decision to use MEF internally with StatLight.

  1. 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.)
  2. 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)

Thoughts?

Aug 12, 2010 at 6:42 PM

There may be a few ways to do this but absolutely for this to work, it has to keep itself apart from the main applications. In other words, obviously the intenal solution for the test host shouldn't impact the application framework that is being tested. I have a similiar issue with my project. It could be a great win showing Microsoft how we can automate some tests with the tool but because the application relies heavily on MEF and some of the tests require composition, it bombs and therefore can't be used. I'd be very interested in hearing any upcoming solutions for this, because the majority of the Silverlight applications I build integrate MEF and DeploymentCatalog, etc.

Coordinator
Aug 12, 2010 at 8:37 PM
Edited Aug 12, 2010 at 9:02 PM

Jeremy,

Sorry I haven't notified anyone on this thread about any updates to this issue. I checked in a fix for this back in early July. http://github.com/staxmanade/StatLight/commit/f09fdcd36d5ba553b5e2ceca6c27f7f26cc8512c

In - theory - you should be able to build from master and everything should be golden.

Please let me know if there are still any issues.

I don't have a specific date for the next "official" release.