Ken Kolda
9/29/2004 8:06:00 PM
I'm sure there are several ways you could potentially deal with this,
including those you mentioned. The easiest way, assuming it's feasible, is
to do exactly what you said: override ISerializable and convert your data
fields to/from .NET native types. This is actually what I would probably do
in the same situation.
A method that might be deemed more "proper" would be to never add to the
class. Instead, create a derived class that includes the new methods you
need. For functions on the server that take this class as an argument, you
declare the function to receive the base class -- that way the client could
pass either the original class or the derived class.
But, for functions that return an object of this type, you'd have to have
two functions -- one for legacy clients and a new one that's you'd write for
your new clients. Old clients wouldn't even know about the new method call.
Clearly, this is more work since you could end up having to duplicate a
number of functions, but it overcomes the issue of figuring out how to
serialize possibly complex objects to native types.
Ken
"Roger Down" <roger.down@email.com> wrote in message
news:%236EWzcipEHA.348@TK2MSFTNGP15.phx.gbl...
> I have several remoting clients which invokes methods on a remoting server
object, hosted on IIS6
> using SAO. These clients will not be changed in the same timeschedule as
the server object. This
> means that the client needs to be robust when it comes to
serializing/deserializing the information
> passed.
>
> The first version of the client uses a serializable struct, which is sent
to the server, and also
> received from the server in various methods. The struct looks like this:
>
> [Serializable]
> public struct MyStruct
> {
> public string MyString;
>
> public MyStruct(string myString)
> {
> this.MyString = myString;
> }
> }
>
> This works fine.
>
> Now at some point there is a need to expand the content of MyStruct. The
struct now looks like this:
>
> [Serializable]
> public struct MyStruct
> {
> public string MyString;
> public ColorEnum Color;
>
> public MyStruct(string myString)
> {
> this.MyString = myString;
> }
>
> public MyStruct(string myString, ColorEnum color)
> {
> this.MyString = myString;
> this.Color = color;
> }
> }
>
> The news clients will work as expected, because they contain both the new
version of MyStruct and
> the enum implementation. The server object will also work as expected,
because it also contain the
> same implementation.
>
> But the older clients now stops working, throwing an
SerializationException, because they now
> receives new elements in the serialized data from the server.
>
> I tried to change the struct to a class, and implementing ISerializable...
If the struct (or class)
> only contains known types, meaning those already defined in the .NET
Framework, it will work. But if
> I implement my own enums or other types, I will get an exception.
>
> My question is this:
>
> 1. What is the correct procedure of implementing such a functionality,
like the one I've tried to
> describe above ? Are there any tricks I can implement using serializing
techniques ?
>
> I've read some articles about this topic, e.g. Jeffrey Richter in MSDN...
but I'm still unsure if he
> solves my problem here...
>
> Another approach might be to never use 'unknown' types in the
implementation... and just use some
> form of string representation of the 'unknown' types... manually convert
those strings to the
> correct types in the client.
>
>
> Best of regards...
>
>
>