Unity 3.5 Silverlight support

Jun 7 at 7:10 AM
I want to discuss my attempt to add Silverlight 5 support to last Unity. Draft of my work can be found at this commit: https://unity.codeplex.com/SourceControl/network/forks/darkman666/Silverlight5/changeset/f0368aa4642bb121993a5f1d5d0fdfd829d09d03.

Main problem of Silverlight support is miss of TypeInfo class in Silverlight and PCL libraries targeting Silverlight. Fortunately, PCL libraries has full-feature Type class (just as in .Net), so we can use it instead of new TypeInfo. So, there is no problems with rewriting TypeInfo access with using Type class or creating some static extension helper that will provide API similar to TypeInfo. So, it is very easy to add Silverlight support to Unity PCL assembly.
When we start work with Tests, Interceptors and RegistrationByConvention, that is not PCL assemblies, we have small problems - we should use different API for Silverlight and Win Store assemblies. I have several solution options:
  1. Add public static helper to Unity assembly (it is PCL, so we can use same Type-API) and always use it helper extensions methods instead of using Type/TypeInfo methods and properties. Disadvantage of such decision will be, that this helper will be visible for all other projects, that use Unity.
  2. Same as (1), but make it internal with InternalsVisibleTo on Unity assembly, that will describe all other assemblies. For now, I selected this option as easiest, but want to discuss it.
  3. Same as (1), but don't make it's method extensions - it will not spam intellisense of all Unity-used project.
  4. Write to version of Type static helper, which will contain extensions methods for Type class, make it internal and add proper version of this class (as link) to each non-PCL project.
  5. Use #ifdef - I don't think that it is an option, really.
Next small problem - PCL assembly with Silverlight has not Monitor.IsEntered method. It is used in SynchronizedLifetimeManager, but we can just skip that check as I suppose or add Monitor.TryEnter(this.lockObj, 0) instead of it.

And last topic to discussion. Earlier Silverlight Unity assembly has Microsoft.Practices.Unity.Silverlight name. So, it will be impossible to use new PCL assembly if other third-parties assemblies already use Unity. Pattern and Practices Prism use Unity - so it will be hard to use new version of it until there will be update of Prism with changed assembly name/version. Unfortunately, looks like new PRISM version doesn't support Silverlight anymore - and I'm not sure if it takes pull requests. To solve this problem, we could create Microsoft.Practices.Unity.Silverlight assembly, that will have TypeForwardedTo attribute, pointing to Microsoft.Practices.Unity for each public Unity 2.1 type. This will allow use new Unity even with old PRISM version (I haven't done it yet).