We are migrating a bunch of services that pass typed datasets to instead use data contracts. The types translate to data contracts really well -- basic properties and collections of other data contract types. And everything works fine -- except
for binary serialization performance compared to typed datasets. Datasets have a pretty well-optimized serialization mechanism so we went to work and implemented ISerializable for our data contracts. That custom serialization meets or beats
the dataset serialization, so we are happy about that.
The problem is that you can't have a type decorated with the DataContract attribute that also implements ISerializable. I was hoping there was some way to host a netTcp binding that would use our custom serialization while also being able to host the
same service using Http and the regular Data Contract Serializer (and other WCF interop goodness). But if a data contract can't implement ISerializable, then I have to duplicate my types (and therefore my contracts) and figure out some wacky inheritance
scheme to avoid duplicating the service code as well.
Is there some way to configure a host to use a custom binary serializer (doesn't *have* to be ISerializable) while preserving the abilty to use the standard data contract features over Http? Thanks,
View Complete Post