WP7: exceptions thrown at player instantiation


It seems the MEF port included with the SMF for WP7 runs into some issues when the player control is instantiated.
For a localized project that supports several languages, two exceptions are thrown per language. Here is the stacktrace:
at System.ThrowHelper.throwVersion37CompatException(ExceptionType newEType, String newString, ExceptionType oldEType, String oldString)
at System.Reflection.Assembly.Load(String assemblyString)
at System.ComponentModel.Composition.Hosting.DeploymentCatalog..ctor()
at Microsoft.SilverlightMediaFramework.Core.PluginsManager.InitializeCompositionContainer()
at Microsoft.SilverlightMediaFramework.Core.PluginsManager..ctor()
at Microsoft.SilverlightMediaFramework.Core.SMFPlayer..ctor()
at System.Reflection.RuntimeConstructorInfo.InternalInvoke(RuntimeConstructorInfo rtci, BindingFlags invokeAttr, Binder binder, Object parameters, CultureInfo culture, Boolean isBinderDefault, Assembly caller, Boolean verifyAccess, StackCrawlMark& stackMark)
at System.Reflection.RuntimeConstructorInfo.InternalInvoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, StackCrawlMark& stackMark)
at System.Reflection.ConstructorInfo.Invoke(Object[] parameters)
at MS.Internal.TypeProxy.<>c__DisplayClass30.<GetCreateObjectDelegate>b__2a()
at MS.Internal.TypeProxy.CreateInstance(UInt32 customTypeId)
And here is an example of the exception message:
File or assembly name 'de/MyProject.resources', or one of its dependencies, was not found.
Looking at the code (with Reflector) of DeploymentCatalog:
public DeploymentCatalog()
List<Type> types = new List<Type>();
AggregateCatalog cat = new AggregateCatalog();
foreach (AssemblyPart part in Deployment.Current.Parts)
        Assembly assembly = Assembly.Load(part.Source.Replace(".dll", string.Empty));
        cat.Catalogs.Add(new AssemblyCatalog(assembly));
CompositionContainer c = CompositionHost.Initialize(new ComposablePartCatalog[] { cat });
int count = c.Catalog.Parts.Count<ComposablePartDefinition>();
this.parts = c.Catalog.Parts;
the part.Source.Replace(".dll", string.Empty) is probably the culprit.
The try catch prevents the application from crashing, but it's still very problematic and very_slow to get 20 exceptions for an app that supports 10 languages, even more on a phone.
Any idea what to change to fix this? Why would SMF even try to touch at the resource dlls anyway?


guillembk wrote Nov 10, 2011 at 9:50 AM

Still an issue with v2.6...

wrote Jul 9, 2012 at 10:22 PM

wrote Feb 22, 2013 at 1:33 AM