By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,732 Members | 824 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,732 IT Pros & Developers. It's quick & easy.

Serializing properties

P: n/a
Hi Folks!

Here's a strange behaviour:

Without a properties SET accessor (see code below), the property will not
serialize.

public class myObject
{

private string _myAttribute;

[XmlAttribute("MyAttrib")]
public string myAttribute
{
get { return _myAttribute; }
set { _myAttribute = value; } //this accessor must be present to
serialize
}

public myObject()
{
_myAttribute="set during construction...";
}

}

I would prefer the property (myAttribute) be accessible only by GET but if I
want it to serialize I must allow the SET. Is there any way around this?

Rein
Nov 15 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Rein,

This makes sense. XML serialization uses the accesor to the property to
set the value, it does not access the fields on the class level. If you
want to get around this, use the SoapFormatter and use regular
serialization.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Rein Petersen" <rm********@bogus.hotmail.com> wrote in message
news:uA**************@TK2MSFTNGP11.phx.gbl...
Hi Folks!

Here's a strange behaviour:

Without a properties SET accessor (see code below), the property will not
serialize.

public class myObject
{

private string _myAttribute;

[XmlAttribute("MyAttrib")]
public string myAttribute
{
get { return _myAttribute; }
set { _myAttribute = value; } //this accessor must be present to
serialize
}

public myObject()
{
_myAttribute="set during construction...";
}

}

I would prefer the property (myAttribute) be accessible only by GET but if I want it to serialize I must allow the SET. Is there any way around this?

Rein

Nov 15 '05 #2

P: n/a
Rein,

You need the set accessor if you are serialising, as you need to provide a
way to de-serialise.

You can apply the "ReadOnlyAttribute" to the property, which prevents the
user from changing the property at design time.

You could probably also have your serialized property completely hidden
(apply the Browsable, and EditorBrowsable attributes), and have another
property with just the Get which is not serialized.

Tim.

"Rein Petersen" <rm********@bogus.hotmail.com> wrote in message
news:uA**************@TK2MSFTNGP11.phx.gbl...
Hi Folks!

Here's a strange behaviour:

Without a properties SET accessor (see code below), the property will not
serialize.

public class myObject
{

private string _myAttribute;

[XmlAttribute("MyAttrib")]
public string myAttribute
{
get { return _myAttribute; }
set { _myAttribute = value; } //this accessor must be present to
serialize
}

public myObject()
{
_myAttribute="set during construction...";
}

}

I would prefer the property (myAttribute) be accessible only by GET but if I want it to serialize I must allow the SET. Is there any way around this?

Rein

Nov 15 '05 #3

P: n/a
> This makes sense. XML serialization uses the accesor to the property
to
set the value, it does not access the fields on the class level. If you
want to get around this, use the SoapFormatter and use regular
serialization.


Hmmm, I can't say I agree it makes sense - I'm not asking the serialization
process to SET the property, but rather to GET it and serialize it.

Is this really a sensible behaviour? Can anyone explain why this is?

Admittedly, I'm not keen on the SoapFormatter because I think SOAP sucks and
I doubt that I will be able to format the resulting serialized xml as I
require. Are there any decent resources detailing customizing the
serializing using the SoapFormatter where I can confirm this?

Rein
Nov 15 '05 #4

P: n/a
Thanks Tim,

Your explanation and suggestions solved my problem.

Rein

"Tim Johnson" <ti******@cae.ca> wrote in message
news:bn**********@dns3.cae.ca...
Rein,

You need the set accessor if you are serialising, as you need to provide a
way to de-serialise.

You can apply the "ReadOnlyAttribute" to the property, which prevents the
user from changing the property at design time.

You could probably also have your serialized property completely hidden
(apply the Browsable, and EditorBrowsable attributes), and have another
property with just the Get which is not serialized.

Tim.

"Rein Petersen" <rm********@bogus.hotmail.com> wrote in message
news:uA**************@TK2MSFTNGP11.phx.gbl...
Hi Folks!

Here's a strange behaviour:

Without a properties SET accessor (see code below), the property will not serialize.

public class myObject
{

private string _myAttribute;

[XmlAttribute("MyAttrib")]
public string myAttribute
{
get { return _myAttribute; }
set { _myAttribute = value; } //this accessor must be present to
serialize
}

public myObject()
{
_myAttribute="set during construction...";
}

}

I would prefer the property (myAttribute) be accessible only by GET but
if I
want it to serialize I must allow the SET. Is there any way around this?

Rein


Nov 15 '05 #5

P: n/a
Rein,

It makes sense because the operation has to go two ways. If you are
able to serialize a value, then you need to be able to read the value from
the object. If you want to de-serialize an value then you need to be able
to write the value to the object. Since the XML Serializer handles both
operations, it needs to know that whatever it can read from, it can also
write to. Granted, the XML serializer could have been coded to ignore
elements that don't have a representation in the object model (and vice
versa), but I think that they wanted to get some sort of type-safety in
there.

The SoapFormatter is going to be different, in the sense that your
properties are not going to be serialized. Rather, your internal fields on
your class are going to be serialized. Now if you have a basic one-to-one
mapping between your fields and your properties, then this is ok. However,
if your properties are a composite of many values in the fields, then you
probably don't want to duplicate the business logic to calculate those
fields. In this case, a better approach would be to have a separate object
which has public read only fields which you can set through the constructor
of the object. Your object would create an instance of this object, setting
the values. Then, it would serialize that using the SoapFormatter. Your
XML will then be easier to manipulate.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Rein Petersen" <rm********@bogus.hotmail.com> wrote in message
news:%2******************@TK2MSFTNGP09.phx.gbl...
This makes sense. XML serialization uses the accesor to the
property to
set the value, it does not access the fields on the class level. If you
want to get around this, use the SoapFormatter and use regular
serialization.
Hmmm, I can't say I agree it makes sense - I'm not asking the

serialization process to SET the property, but rather to GET it and serialize it.

Is this really a sensible behaviour? Can anyone explain why this is?

Admittedly, I'm not keen on the SoapFormatter because I think SOAP sucks and I doubt that I will be able to format the resulting serialized xml as I
require. Are there any decent resources detailing customizing the
serializing using the SoapFormatter where I can confirm this?

Rein

Nov 15 '05 #6

P: n/a
Nicholas,

Thanks for the insightful distinctions between Xml Serializer and
SoapFormatter. I now understand how your suggestion to use the SoapFormatter
(ableit for an unconventional purpose), can provide flexibility in
conforming serialization to a desired schema.

If the goal of serialization is to represent a snapshot of an object's
state, then serializing it's private fields (over public properties) makes
sense.

I'm certain this is my solution.

Thanks again!

Rein
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:eS*************@TK2MSFTNGP11.phx.gbl...
Rein,

It makes sense because the operation has to go two ways. If you are
able to serialize a value, then you need to be able to read the value from
the object. If you want to de-serialize an value then you need to be able
to write the value to the object. Since the XML Serializer handles both
operations, it needs to know that whatever it can read from, it can also
write to. Granted, the XML serializer could have been coded to ignore
elements that don't have a representation in the object model (and vice
versa), but I think that they wanted to get some sort of type-safety in
there.

The SoapFormatter is going to be different, in the sense that your
properties are not going to be serialized. Rather, your internal fields on your class are going to be serialized. Now if you have a basic one-to-one
mapping between your fields and your properties, then this is ok. However, if your properties are a composite of many values in the fields, then you
probably don't want to duplicate the business logic to calculate those
fields. In this case, a better approach would be to have a separate object which has public read only fields which you can set through the constructor of the object. Your object would create an instance of this object, setting the values. Then, it would serialize that using the SoapFormatter. Your
XML will then be easier to manipulate.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Rein Petersen" <rm********@bogus.hotmail.com> wrote in message
news:%2******************@TK2MSFTNGP09.phx.gbl...
This makes sense. XML serialization uses the accesor to the

property
to
set the value, it does not access the fields on the class level. If you want to get around this, use the SoapFormatter and use regular
serialization.


Hmmm, I can't say I agree it makes sense - I'm not asking the

serialization
process to SET the property, but rather to GET it and serialize it.

Is this really a sensible behaviour? Can anyone explain why this is?

Admittedly, I'm not keen on the SoapFormatter because I think SOAP sucks

and
I doubt that I will be able to format the resulting serialized xml as I
require. Are there any decent resources detailing customizing the
serializing using the SoapFormatter where I can confirm this?

Rein


Nov 15 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.