How can we transparently serialize Dataset ExtendedProperties in WCF?

Question

We are migrating from Remoting to WCF a very big application that makes intensive use of DataSets. We use the ExtendedProperties of the DataSets' tables to store a graph of objects containing special information we need at client side.

In our Remoting implementation we did add to the channel stack a client and a server channels to check if the message contained a dataset and use a xml serializer to be able to send ExtendedProperties through the wire (you may know that the dataset serializer does a ToString() of the elements found into the ExtendedProperties).

We did it that way so it was transparent to the business rules and UI developers.

What should we override or implement in WCF to be able to manage the DataSet before it is serialized to xml/soap by the wcf channel? Is it possible?

Note: I already know we have to avoid using datasets in wcf, but we have more than 200 forms using datasets and changing them all is not a option right now.

Many thanks!

Answer 1

I wonder if you can't swap the serializer by adding a behaviour attribute at each end... given an XmlReader/XmlWriter, the approach of:

dataset.WriteXml(xmlWriter, XmlWriteMode.WriteSchema);

and

dataset.ReadXml(xmlReader, XmlReadMode.ReadSchema);

seems to work (i.e. extended properties are respected), so you should be able to write a behaviour that detects DataSet and swaps to a custom serializer - like this (attribute | behaviour | serializer) - but probably simpler. I can take a look later if that isn't enough to get started...

Answer 2

You might consider switching to NetDataContractSerializer. It is capable to serialize all serializable .NET types, including even the ones supporting ISerializable, and it fully handles cycles in such graphs.

But this will work only if you're going to consume your WCF service by a .NET client.

Answer 3

Hi! First of all thanks for your answers. I've finally did find how to change the serializer with a mix of Marc's answer and an entry of Nicholas Allen's Indigo Blog.

Thank you.