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).