Help chosing the best path forwards - Reflection and serialisation

[Kalisto]

Ive been asked to investigate why a customers system doesnt work (.net 2005), and eventually I have found the issue.

The system is a subset of a big enterprise solution, concerned with messaging.

The objects are passed about via MSMQ, using Binary Serialisation, and the objects were created from XML Schema (by xsd).

The schema were recently extended, and new properties to the objects added. These properties are all optional, which means that the optional parameters all have an additional ParameterSpecified Boolean, with the XmlIgnore Attribute.

Now when these objects are populated from the database via a routine that uses reflection, then the new properties are being set, But the PropertySpecified Flag is not (as a corresponding column doesnt exist in the DataRow).

Looking through the PropertyInfo object for the optional property shows that there are no attributes on the objct at this point.

As I see it I have 4 options, none of which fill me with joy.

1) Modify the reflection code, so that each time I find a property I then look to see if it also has a Specified property and set that to.

2) Create an Attribute and apply it to the optional parameters. - Not a good choice as it will need to be put back into the class definition by hand if the objects are regenerated at a later date.

3) Modify the classes again, and if the property is accessed, then set the Specified parameter - Has the same issues as 2, but has less impact on the reflection code as I dont need to examine attributes.

4) Modify the schemas and make these objects mandatory - I suspect that there is no way I'll get this past the business, and it causes all other kinds of problems.

So I guess Im asking, can anyone see an option 5?

 

[jmeckley]

add a versioning property. depending on the version, (de)serialize the messages a specific way. if there is no versioning (previous messages) then default to the original serialization. a version number would be required for all new messages.

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[Kalisto]

Thanks. The issue I see with that is that if they extend the system in the future, then this will mean that custom serialisation code will need to be written for each type of object when it is pulled from the database, Which will mean a recompile / redeploy.

Using Option 1, although it is Kludgy, it does mean that If they extend / change the objects, then the database / serialisation code remains the same reflection routine that parses the data rows, so thats one less facet to redeploy.

On the other hand, maybe that will make them think twice before changing the system, so it could be worth a shot.

I'll write up the implications of both scenarios and let those that are paid to make decisions like this stick their necks out for once.

Thanks

K

 

[chiph]

They can also change the generated classes to be Partial classes in order to facilitate extension.

This just puts the burden on the deployment folks -- you need to make sure that both the sender and recipient have the same version of the extension assembly. So adding a version property to the serialization/deserialization routines may still be required to ensure the correct assembly gets loaded.

But in general, this is a common problem with defining objects that are: enterprise, shared, and generated. There is no 'correct' answer -- just answers that suck to greater or lesser degrees.

Chip H.


____________________________________________________________________
www.chipholland.com