Unity and Silverlight

Aug 20, 2008 at 1:58 PM


Firstly, as a newbie to this forum I would just like to say 'Great Work Everybody' - the discussions and source has really helped me understand the opportunites / drawbacks (special thanks to Michael Sync for his upload of Unity for Silverlight2B2) and secondly I apologise to those who subscribe to the Prism Contrib for WPF forum for raising this discussion twice.

My question is 'I was wondering if anyone out there was considering how Unity.Configuration was going to work with Silverlight?'

My scenario is I want 3rd parties to be able to inject their own modules at run-time (i.e. I don't want to have to reference them in my project) into regions I have specifically exposed to them - basically I'm allowing 3rd parties to extend my application.

Originally I had thought of calling a WCF service which 'discovered' the modules on the server using a Configuration File on the server. The service would return a List<IModule> but obviously this would not work because how would the Silverlight Client serialize IModule. 

So I was wondering whether or not the Client's Isolated Storage could be used, put (very) simply it would do the following: 

  1. The Client's additional configuration (what addons were available) would be obtained using a WCF service, the result being simply a piece of XML
  2. 'Unity for Silverlight' would be altered to search the application installed assemblies directory first, if not found it would check the client's local isolated storage
  3. If not found in either locations it would download the additional assemblies from the server to the client's isolated storage.

Does this sound mad? Has anyone tried this? Does any of it sound unfeasible, i.e. are there any security issues in using the isolated storage?

Any comments / suggestions would be appreciated



Aug 21, 2008 at 7:27 AM

I've got something to work for my situation:

  1. Use a WCF Service to download the configuration for the composite application, i.e. determine what addins are available. The configuration will have the http:// location of the assembly and the name of the class (module) that implememts IModule
  2. Use a WebClient to download the assembly.
  3. Use AssemblyPart.Load(e.Result) to load the assembly
  4. Use Assembly.CreateInstance(...) to create n instance of the class that implements IModule
  5. Execute Initialise(container) on the addin class
  6. The addin is then responsible for its own configuration using the client's container (RegionManagerService etc...)

Having not being party to previous discussions my only concern is I am not using DILight, rather I am using SLUnity should this matter. My reason for using SLUnity is because I need to use property injection rather than constructor injection, that's because the constructor has already been called as part of the CreateInstance.

Based on this solution I can allow addins to be added to my composite application dynamically and by using the client's container they can subscibe to the pre-registered instances of the client's services.

This doesn't solve 'how do I configure the container for the client's implementation?' - for that I still think Unity.Configuration would help. 

What do people think? Any comments / concerns, should I be using SLUnity over DILight? 

Aug 21, 2008 at 9:31 AM

Please refer to this thread http://www.codeplex.com/CompositeWPFContrib/Thread/View.aspx?ThreadId=33819