This post is part of a series about WCF extensibility points. For a list of all previous posts and planned future ones, go to the index page.This post takes a detour from the normal flow of the series, since I was working on a scenario last week which I think will add value to the series as a whole. On the post about contract behaviors, I showed an example of how to hook up a custom serializer to the WCF pipeline. That sample used the DataContractSerializerOperationBehavior extensibility in which you could inherit from that class, override the CreateSerializer methods and replace that behavior on the operation with your own custom class. That’s fairly simple and has been done extensively in WCF. However, this doesn’t work in Silverlight. This post isn’t about one specific extensibility point, but about a scenario which can be covered by the extensibility points already covered in this series, in a different platform. The WCF portions of Silverlight is a subset (*) of the full framework. Due to many restrictions in the Silverlight platform, such as the sandbox, support for multiple OS, and primarily size (the runtime download time could not be too large, otherwise people might give up installing it), many features in the full WCF didn’t make it into SL. Other features actually went in, but in order to reduce the (large) number of extensibility points, they were made internal. The class DataContractSerializerOperationBehavior is one of those which didn’t make the cut, and for most of the cases it hasn’t been a problem – SL has been released for about 3 years now and only recently I’ve seen a couple of requests for being able to replace the serializer in SL. (*) It’s not really a proper subset, as there are some features in SL which aren’t available in the full framework, such as the classes in the System.Json namespace; they may eventually make it to the framework, but at this time they’re only available in the WCF Codeplex site.
Real World Scenario: expanding custom serialization to SilverlightThe first thing to be able to replace the DataContractSerializerOperationBehavior in SL is to actually find out what it does at the client side. I’ve been using Reflector (while it’s free) and it shows that the ApplyClientBehavior method does two things: determines whether the operation input / output should be serialized (if the operation uses untyped messages, then no serialization is necessary, and it then creates the client formatter which will be used to serialize / deserialize the request / reply. So like in the desktop case, our new operation behavior will do something similar. Also, like in the DataContractSerializerOperationBehavior, I’ve made the method CreateSerializer virtual, so that it can be extended to easily replace the serializer. Read more: Carlos' blog
QR:
Real World Scenario: expanding custom serialization to SilverlightThe first thing to be able to replace the DataContractSerializerOperationBehavior in SL is to actually find out what it does at the client side. I’ve been using Reflector (while it’s free) and it shows that the ApplyClientBehavior method does two things: determines whether the operation input / output should be serialized (if the operation uses untyped messages, then no serialization is necessary, and it then creates the client formatter which will be used to serialize / deserialize the request / reply. So like in the desktop case, our new operation behavior will do something similar. Also, like in the DataContractSerializerOperationBehavior, I’ve made the method CreateSerializer virtual, so that it can be extended to easily replace the serializer. Read more: Carlos' blog
QR: