EDN Admin
Well-known member
I am working on a project which uses the IxmlSerializable interface for serializing/deserializing of complex data to a persisted file. Im not sure why the prior development team chose IXmlSerializable as it seems to have led to some very klunky code paths.
Basically, classes evolved properties were added, deleted, had name changes, changed types etc. This was handled by requiring the developer to version a serialized type each time one of these changes were made:
if(_version < 5)
{
if(_version < 4)
...
}
else if(_version < 6)
{
...
}
hopefully, you get the picture.
The big problem is of course that the users have data which is unique to them, such that when they report a serialization issue, which is frequent, we have to have them send in their entire data sets to reproduce the issue.
I am tempted to recommend that we scrap the IXmlSerializable implementation in favour of ISerializable. I would be using a BinaryFormatter. In my testing, it is much more forgiving in how it handles changes to serialized classes, and it is much more performant.
it doesnt appear that I have to continually resort to ugly switch code when I make basic changes. While I havent tested it, I understand that it handles Collections of objects where IXmlSerializable does not.
Yes, we would not be able to support legacy files (of data serialized by IXmlSerializable) but we can live with that.
I am not an expert with the intracacies of .NET serialization so before I propose this change, I would like to hear from the experts as to whether or not this sounds like a reasonable proposal.
Thanks,
<
Hedley<br/>
View the full article
Basically, classes evolved properties were added, deleted, had name changes, changed types etc. This was handled by requiring the developer to version a serialized type each time one of these changes were made:
if(_version < 5)
{
if(_version < 4)
...
}
else if(_version < 6)
{
...
}
hopefully, you get the picture.
The big problem is of course that the users have data which is unique to them, such that when they report a serialization issue, which is frequent, we have to have them send in their entire data sets to reproduce the issue.
I am tempted to recommend that we scrap the IXmlSerializable implementation in favour of ISerializable. I would be using a BinaryFormatter. In my testing, it is much more forgiving in how it handles changes to serialized classes, and it is much more performant.
it doesnt appear that I have to continually resort to ugly switch code when I make basic changes. While I havent tested it, I understand that it handles Collections of objects where IXmlSerializable does not.
Yes, we would not be able to support legacy files (of data serialized by IXmlSerializable) but we can live with that.
I am not an expert with the intracacies of .NET serialization so before I propose this change, I would like to hear from the experts as to whether or not this sounds like a reasonable proposal.
Thanks,
<
Hedley<br/>
View the full article