version resistant serialization

  • Thread starter Thread starter Lloyd Dupont
  • Start date Start date
L

Lloyd Dupont

I wrote a custom channel to do custom remoting :)
I would like it to be version resistant.

Let say I have a customer having an old version of the product and an other
having a newer version with some different field, sigh...

I would like the communication to kind of try to work anyway.

I know I could have implement ISerializable interface on my data object but
let's look in an other direction, I would like to have a custom
IServerFormatterSinkProvider which return a custom formatter sink.

However I would like to avoid writing a new complete formatter myself, I
rather use the BinaryFormatter class and kind of hook into it.

Anyway of doing that ?
Any links ?

Any help appreciated :)
 
Hi Lloyd,
Unfortunately the V1 serialization framework was not designed to be version
tolerant. This has been added for Whidbey (through the use of the
OptionalFieldAttribute), but that won't be much help if you can't use the
beta 2.0 SDK.

It is possible (although not technically supported) for you to roll this
yourself in v1 without having to re-implement the entire formatter.
Probably what you're looking for is a formatter that will behave the same
as the BinaryFormatter, except it will ignore extra serialization data in
the stream that it doesn't recognize, and will use a default value for a
field if a value is not included in the stream (possibly only when the
field is annotated with an attribute as was done for Whidbey). If you had
this, you'd still need to be careful when making changes to your data
structures, but at least some form of forwards and backwards compatibility
would be possible.

The actual amount of code necessary to implement this isn't very much (as
long as you're not terribly concerned about performance), however it
requires a pretty good understanding of the serialization mechanism. I
don't remember the precise steps you need to take to implement this (I've
done it, but it was before I worked for MS), but I can give you some hints
if you're interested. If you haven't already, I suggest you grab a copy of
the rotor sources (http://msdn.microsoft.com/net/sscli/) and poke around a
bit in the System.Runtime.Serialization namespace. If you omit all the
caching logic, you can re-implement the main serialization and
deserialization logic of the formatter sink using the public methods
exposed by the FormatterServices class without writing much code.

If you do manage to get this working, it would be a great sample to post to
gotdotnet.com. Let me know if you run into any problems or have any more
questions. I can't promise to have the answers (I'm not part of the team
responsible for serialization), but I'll do what I can to help - especially
if you're willing to post your solution publicly.

Rick
 
Back
Top