Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Why is SerializableAttribute not included in the Silverlight version of FCL?
And also, BinaryFormatter is not in there either.
I am not looking for an alternative solution, I am just curious about the fact.
Is binary serialization fundamentally against some of Silverlight’s design rules?
Firstly, Silverlight has different permission rules – much harder to get at the private fields. Of course, for the FCL designers I don’t think this would be a problem – they could just code that into the runtime (but re-creating a potential way of side-stepping the sandbox).
Perhaps the biggie is that Silverlight doesn’t need (or want) to support “remoting”, which is the main reason it has to exist in the main .NET BCL. Of course, remoting is out of fashion generally, but needs to be in core .NET for backwards compatibility.
A third reason could well be the very nature of
BinaryFormatter; many classes in SL have different implementations inside the SL runtime, to account for different features and available types / security / etc. This makes it virtually impossible to have it wire compatible with the core .NET runtime. So you wouldn’t be able to share it with your server code.Overall, then, it makes great sense to just cut it. For app<===>server, contract-based serializers exist; and other (dare I say: better) binary serializers are available that avoid all these problems (i.e. are fully portable).