Object Serialization Offsets the Properties

Object Serialization Offsets the Properties

Old forum URL: forums.lhotka.net/forums/t/7278.aspx


jw56578 posted on Wednesday, July 15, 2009

What would cause this problem only with one certain class from my code base, which has been coded like every other object and this behavior is only observed on our production environment.
When the object is serialized on server and returned to client, the values in the properties are offset. For example i will debug on the server and see that the object data is loaded properly FirstName = "Jon", LastName = "smith", but when it gets back to the client in debug i see, FirstName = "smith" LastNamt = "Jon" ??

JonStonecash replied on Wednesday, July 15, 2009

I would check the versions of the binaries on the client and server.  This sounds like a mismatch in the execution binaries. 

Jon Stonecash

JoeFallon1 replied on Wednesday, July 15, 2009

It might also matter which version of CSLA you are using. And whether or not you use the new Property syntax or not. The original property syntax reuiqred the use of a forceInit trick to ensure that Properties in an inheritance hierarchy lined up correctly.  Newer versions do not require that trick anymore.

Joe

 

skagen00 replied on Wednesday, July 15, 2009

I would second what Joe said... a symptom of not doing the forceinit trick would be the data loading in an "offset" position...

It wouldn't switch two columns with one another that appear in the same class (such as the example you gave above) but I suspect that you were just trying to convey that values were loading into the wrong properties.

jw56578 replied on Thursday, July 16, 2009

But is there any explanation why this only occurs to one business and only intermittently

jw56578 replied on Thursday, July 16, 2009

could someone post an example of the forceInit trick

rsbaker0 replied on Thursday, July 16, 2009

Here is a post from Rocky himself on this...

http://forums.lhotka.net/forums/post/26436.aspx

(I see some references that indicate this is no longer necessary as of CSLA 3.6.2, but I haven't confirmed this)

Copyright (c) Marimer LLC