Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles
(untagged)

Silverlight Mobile: Scouting with Castle Windsor

0.00/5 (No votes)
15 Apr 2010 1  
Silverlight mobile: Scouting with Castle Windsor

OK, so round one of me Vs Silverlight Mobile was definitely a learning curve! Having got so used to MVVM with WPF, I was expecting the experience to be pretty much the same in Silverlight. I was wrong! Now I’m not going to moan as I’m sick of doing that. Despite the shortcomings of Silverlight Vs WPF, I’m going to just go through them and start thinking about how I can overcome them so that the WPF - Silverlight transition is as seamless as I can make it.

So firstly: Silverlight DataTemplates have no DataType property…. WHAT? I have to admit at first I was appalled thinking this would immediately put my beloved MVVM at risk. But although it was a very nice feature, life is too short and it should not put testability of ViewModels as risk so I’m thinking AttachedProperties will help me with that anyway!

Can we still use Castle Windsor with Silverlight?

The short answer is: yes we can. However, there are a couple of minor things to be aware of and hopefully I can save you some time by listing them here.

Firstly: Castle Windsor 2.1.1 now ships with Silverlight versions of the binaries. You must use these with Silverlight because the standard DefaultKernel inherits from MarshalByRefObject which is not supported in Silverlight.

Second: Adding the castle references to your Silverlight projects results in a compile time error:

Error1The "ValidateXaml" task failed unexpectedly.
System.IO.FileLoadException: Could not load file or assembly <x> or one of its dependencies.
Operation is not supported. (Exception from HRESULT: 0×80131515)
File name: …Castle.Windsor.dll’ System.NotSupportedException: 
An attempt was made to load an assembly from a network location which would have 
caused the assembly to be sandboxed in previous versions of the .NET Framework. 
This release of the .NET Framework does not enable CAS policy by default, 
so this load may be dangerous. If this load is not intended to sandbox the assembly, 
please enable the loadFromRemoteSources switch. 
See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.</x>

To fix this, simply right click your assembly in file explorer (not in Visual Studio) and go to properties. At the very bottom on the right, there is an ‘Unblock’ button. Click it and re-compile. I’m not going to try and explain it. If you want more information, visit MSDN here for help on the loadFromRemoteSources element.

Unblock assemblies

 

Unblock assemblies

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here