This project has moved and is read-only. For the latest updates, please go here.

Silverlight startup pattern with CompositionHost initialization

Jul 7, 2010 at 5:31 PM

I'm looking for advice, warnings, etc about the best startup pattern for a Silverlight application that has some side case issues.

- I have converters defined in App.xaml. At least one of these converters uses MEF via SatisfyImports
- I am adding custom initialization (CompositionHost.Initialize) for other reasons

I currently call InitializeComponent in the App.xaml.vb constructor (which creates the converter)

I currently call composiiton from the Application_Startup event. This is too late because the converter has been composed so I get the error:

{System.InvalidOperationException: The container has already been initialized either by another call to InitializeContainer or by someone causing the default container to be constructed. Ensure that InitializeContainer is one of the first things that happens in the application host to ensure that it is ready for the first composition.     at System.ComponentModel.Composition.Hosting.CompositionHost.Initialize(CompositionContainer container)     at System.ComponentModel.Composition.Hosting.CompositionHost.Initialize(ComposablePartCatalog[] catalogs)     at AppSilverlight2.App.Compose()}

I could fix this by composing in the App.xaml constructor. Man does that seem like a bad idea, but maybe I'm overreacting.

I could fix this by moving any constructors requiring compositoin to local access. Man do I know that's a bad idea.

I could moveI InitializeComponent to the Startup, but I don't even know if that would run and it seems a really bad idea to change the expected startup sequence that drastically.

So, does anyone see any other suggestions, or think any of these are the greater or lesser of the available evils?

Anyone else run into this? I can't be the only person that ever put SatisfyImports in a value converter.