2
Vote

WP7: exceptions thrown at player instantiation

description

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)
{
    try
    {
        Assembly assembly = Assembly.Load(part.Source.Replace(".dll", string.Empty));
        cat.Catalogs.Add(new AssemblyCatalog(assembly));
    }
    catch
    {
    }
}
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?

comments

guillembk wrote Nov 10, 2011 at 8:50 AM

Still an issue with v2.6...