Hello,

I have a situation where I would like to perform custom serialization
and deserialization of an existing .NET framework object (specifically,
System.DateTime). Is there a common paradigm here, for how I can
override the default behavior of DateTime serialization and provide my
own? I want to use this custom serialized DateTime in many places, and
don't want to provide custom serialization routines for every single
object that uses one of these DateTimes, it just seems easier to just
apply it directly to the DateTime object so that everywhere I use it,
it automatically picks up my new method.

The reason I'm doing this is because I'm doing .NET remoting with a 2.0
server and clients which might be either 1.1 or 2.0. I want the
serialization to behave correctly no matter what version the client is.

I've already done a few tests on serializing between the two versions .net
(1.1 and 2.0) with good results (didn't test DateTime though). What exactly
is the difference between the two versions ?

Mike
http://www.seeknsnatch.com

"Zachary Turner" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hello,
>
> I have a situation where I would like to perform custom serialization
> and deserialization of an existing .NET framework object (specifically,
> System.DateTime). Is there a common paradigm here, for how I can
> override the default behavior of DateTime serialization and provide my
> own? I want to use this custom serialized DateTime in many places, and
> don't want to provide custom serialization routines for every single
> object that uses one of these DateTimes, it just seems easier to just
> apply it directly to the DateTime object so that everywhere I use it,
> it automatically picks up my new method.
>
> The reason I'm doing this is because I'm doing .NET remoting with a 2.0
> server and clients which might be either 1.1 or 2.0. I want the
> serialization to behave correctly no matter what version the client is.
>

The difference is in 2.0 DateTimes are serialized with one extra field.
A 2 bit (i think) value specifying whether the following serialized
time is Utc or Local time. When .NET 1.1 tries to deserialize this, it
obviously fails and throws an exception. As far as I know many objects
work successfully when serializing across versions, but DateTime seems
to be one of the exceptions to the rule.

Is there any way to override the default deserialization behavior for
the entire type?

Michael Klingensmith wrote:
> I've already done a few tests on serializing between the two versions .net
> (1.1 and 2.0) with good results (didn't test DateTime though). What exactly
> is the difference between the two versions ?
>
> Mike
> http://www.seeknsnatch.com
>
> "Zachary Turner" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > Hello,
> >
> > I have a situation where I would like to perform custom serialization
> > and deserialization of an existing .NET framework object (specifically,
> > System.DateTime). Is there a common paradigm here, for how I can
> > override the default behavior of DateTime serialization and provide my
> > own? I want to use this custom serialized DateTime in many places, and
> > don't want to provide custom serialization routines for every single
> > object that uses one of these DateTimes, it just seems easier to just
> > apply it directly to the DateTime object so that everywhere I use it,
> > it automatically picks up my new method.
> >
> > The reason I'm doing this is because I'm doing .NET remoting with a 2.0
> > server and clients which might be either 1.1 or 2.0. I want the
> > serialization to behave correctly no matter what version the client is.
> >

Hi Zachary,

Take a look at the following interfaces:

System.Runtime.Serialization.ISurrogateSelector
System.Runtime.Serialization.ISerializationSurrogate

They allow you to provide serialization and deserialization logic that replaces the default logic for any given Type.

SurrogateSelector class on MSDN (has an example):
http://msdn2.microsoft.com/en-us/lib...eselector.aspx

--
Dave Sexton

"Zachary Turner" <(E-Mail Removed)> wrote in message news:(E-Mail Removed)...
> The difference is in 2.0 DateTimes are serialized with one extra field.
> A 2 bit (i think) value specifying whether the following serialized
> time is Utc or Local time. When .NET 1.1 tries to deserialize this, it
> obviously fails and throws an exception. As far as I know many objects
> work successfully when serializing across versions, but DateTime seems
> to be one of the exceptions to the rule.
>
> Is there any way to override the default deserialization behavior for
> the entire type?
>
> Michael Klingensmith wrote:
>> I've already done a few tests on serializing between the two versions .net
>> (1.1 and 2.0) with good results (didn't test DateTime though). What exactly
>> is the difference between the two versions ?
>>
>> Mike
>> http://www.seeknsnatch.com
>>
>> "Zachary Turner" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>> > Hello,
>> >
>> > I have a situation where I would like to perform custom serialization
>> > and deserialization of an existing .NET framework object (specifically,
>> > System.DateTime). Is there a common paradigm here, for how I can
>> > override the default behavior of DateTime serialization and provide my
>> > own? I want to use this custom serialized DateTime in many places, and
>> > don't want to provide custom serialization routines for every single
>> > object that uses one of these DateTimes, it just seems easier to just
>> > apply it directly to the DateTime object so that everywhere I use it,
>> > it automatically picks up my new method.
>> >
>> > The reason I'm doing this is because I'm doing .NET remoting with a 2.0
>> > server and clients which might be either 1.1 or 2.0. I want the
>> > serialization to behave correctly no matter what version the client is.
>> >
>