Loading SMF Player with MEF

Jun 18, 2010 at 5:30 PM

I am attempting to load an SMF v2.0 player through MEF.  The player itself seems to load in to the parent assembly just fine.  I am running in to an issue when I attempt to play media though.  I step through the code and they PlaylistItem is queued.  The SMF player does not seem to initialize the download of the SmoothStreaming Plugin to play back the media.  I'm not extremely familiar with MEF yet so I'm wondering if there is a conflict when you have two seperate AggregateCatalogs.  My parent application instantiates an AggregateCatalog for itself and SMF in turn instantiates its own for loading its plugins.  Is there some sort of conflict there?

Jul 2, 2010 at 12:39 AM

I would not expect there to be a conflict.  Are you seeing any errors occur?  As long as you have not set SMFPlayer.AutoPlay/AutoLoad to false it should begin playing once the playlist is queued.  Have you included the Microsoft.SilverlightMediaFramework.Plugins.SmoothStreaming.dll in your .XAP?

Jul 2, 2010 at 4:43 PM

Thank you very much for the reply.  Here is a little more information that may help us figure out what I'm doing wrong.  No errors occur, and AutoPlay & AutoLoad are both set to true.  Microsoft.SilverlightMediaFramework.Plugins.SmoothStreaming.dll is referenced in the player xap but it seems that SMF cannot find the plugin to load from there.  Here is a little bit of the architecture behind the project


Player.xap (this is where SMF dll's are referenced)

The Bootstrapper dynamically loads Player.xap via MEF.

What is interesting is that if I reference add a reference to Microsoft.SilverlightMediaFramework.Plugins.SmoothStreaming.dll in the Bootstrapper then SMF is able to find the plugin properly and the video will play.  So it seems that even though all my dll's are referenced properly in Player.xap they cannot be seen by SMF's implementation of MEF within that project.

Referencing the dll's in the Bootstrapper project destroys the intended seperation of the Player and the Bootstrapper as the intention is to be able to swap out any Player using MEF (be it SMF based or otherwise).  As I claimed before, I am not extremely familiar with MEF so any help is appreciated.  If however this is something that I should turn to the general MEF community as well then please let me know.

Jul 7, 2010 at 6:51 PM

I believe I may have figured out the issue.  By default the SMF PluginsManager only loads dll's from the current xap.  In my case that is the BootStrapper.xap.  The SMF dlls do not live in this xap.

So I then attempted to leverage the method PluginsManager.BeginAddExternalPackage(Uri xapLocation).  By specifying the Player.xap to this method it would make sense that the PluginsManager would then load all the SMF plugins properly form that xap.  Unfortunately this was not the case.  I tracked the bug down to the following code snippet from PluginsManager.cs.  The line in RED is what was missing from the SMF code.  The dowloaded catalog is never added to the PluginsCatalog thereby never making the exported parts available to the PluginsManager.  Adding that line properly loaded the plugins in to the proper lists.

        private void Catalog_DownloadCompleted(object sender, AsyncCompletedEventArgs e)
            var catalog = sender as DeploymentCatalog;
            if (catalog != null)
                if (e.Error != null)
                    AddExternalPackageFailed.IfNotNull(i => i(this, catalog.Uri, e.Error));
                else if (!e.Cancelled)
                    AddExternalPackageCompleted.IfNotNull(i => i(this, catalog.Uri));

Jul 8, 2010 at 5:08 PM

cchao, thanks for passing this information along, the bug has been fixed in the current release version.