I have an application that runs on a web server that sends data to
clients over a TCP socket. The data comes from a class that has been
serialized. The class exists in a library (a DLL). The customer
receives this serialized data with a client application I wrote. They
also have the same DLL, so that when the data received is
deserialized, it will be deserialized into the same type of class that
was used on the server.
I have a problem tyring to figure out how to handle updates with the
DLL and making sure that the deserialization works. For instance,
let's say I now add a new property to the class on the server. If the
customer gets a copy of the new DLL and provided I send serialized
data that matches what the client expects, everything is well.
But in a not so perfect world, some customers may choose not to
upgrade. So I now need to send serialized data in such a way that one
client who uses the old DLL can receive the data formatted as it was
originally while another client using the newer DLL can also use the
newer data.
The question is, on the server side, how do I make a distinction
between the two clients? And on the client side, how can I guarantee
that the client will use the correct version of data?
Unfortunately, if there is any mismatch in the number of number of
properties or methods between what is being deserialized and what the
class expects, the deserialization will not succeed.
By the way, I'm using the SOAP formatter for serialization rather than
the binary formatter. I've noticed that the binary formatter stores
the version of the expected DLL whereas the SOAP version doesn't. If I
were to use the binary formatter, I might be able to use the version
information to make destinctions. On the other hand, I can still use
the SOAP formatter and still store the version information because I
don't send the SOAP as-is. I package the SOAP inside another XML
structure, which can contain anything I want.
Your suggestions are welcomed.
Johann Blake
clients over a TCP socket. The data comes from a class that has been
serialized. The class exists in a library (a DLL). The customer
receives this serialized data with a client application I wrote. They
also have the same DLL, so that when the data received is
deserialized, it will be deserialized into the same type of class that
was used on the server.
I have a problem tyring to figure out how to handle updates with the
DLL and making sure that the deserialization works. For instance,
let's say I now add a new property to the class on the server. If the
customer gets a copy of the new DLL and provided I send serialized
data that matches what the client expects, everything is well.
But in a not so perfect world, some customers may choose not to
upgrade. So I now need to send serialized data in such a way that one
client who uses the old DLL can receive the data formatted as it was
originally while another client using the newer DLL can also use the
newer data.
The question is, on the server side, how do I make a distinction
between the two clients? And on the client side, how can I guarantee
that the client will use the correct version of data?
Unfortunately, if there is any mismatch in the number of number of
properties or methods between what is being deserialized and what the
class expects, the deserialization will not succeed.
By the way, I'm using the SOAP formatter for serialization rather than
the binary formatter. I've noticed that the binary formatter stores
the version of the expected DLL whereas the SOAP version doesn't. If I
were to use the binary formatter, I might be able to use the version
information to make destinctions. On the other hand, I can still use
the SOAP formatter and still store the version information because I
don't send the SOAP as-is. I package the SOAP inside another XML
structure, which can contain anything I want.
Your suggestions are welcomed.
Johann Blake