XmlSerializer only serializes fields with getters & setters?

[Ethan Strauss]

Hi,
I am using XML serialization for the first time and I have noticed
something unexpected. The object I am serializing contains a field

private NumericSettings _numericSettings;

public NumericSettings NumericSettings
{
get { return _numericSettings; }
}
which is not being serialized, but I would like it to be. When I created a
setter for this field, it was serialized correctly.
private NumericSettings _numericSettings;

public NumericSettings NumericSettings
{
get { return _numericSettings; }
set {_numericSettings = value;}
}

Is this expected behavior? If so, is there a way I force serialization
without creating a setter? I don't want that field to be settable.

Thanks!
Ethan

ps. I am writting in C#.Net 2.0 in a Windows Forms app.

 

[Marc Gravell]

Well, you could implement IXmlSerializable and do the work yourself,
but for vanilla XmlSerializer, that is simply how it works.

However, if you use DataContractSerializer, you can specify
[DataMember] against private properties / fields.

Marc

 

[Jeroen Mostert]

I am using XML serialization for the first time and I have noticed
something unexpected. The object I am serializing contains a field

private NumericSettings _numericSettings;

public NumericSettings NumericSettings
{
get { return _numericSettings; }
}
which is not being serialized, but I would like it to be. When I created a
setter for this field, it was serialized correctly.
private NumericSettings _numericSettings;

public NumericSettings NumericSettings
{
get { return _numericSettings; }
set {_numericSettings = value;}
}

Is this expected behavior?

Yes. XmlSerializer can handle public fields and public read-write properties
only. It's all there in the manual:
http://msdn.microsoft.com/library/182eeyhh(VS.80)

If so, is there a way I force serialization
without creating a setter? I don't want that field to be settable.

Then you can't really use XmlSerializer, at least not in the convenient way.

There are several solutions to this problem, but they're more workarounds
than solutions. The most obvious is probably to make the setter private and
implement IXmlSerializable instead of using the default behavior.
Unfortunately, this negates the most important benefit of XmlSerializer (the
ability to declaratively control serialization).

You can use a special class that's only for serialization, and convert your
"real" objects to and from. This forces you to cleanly separate your
business objects from your serialization objects, which is a blessing and a
curse. It tends to get tedious quickly. You can combine this with solution
#1 to get the best of both worlds (use XmlSerializer declaratively on your
serialization type but define your business type in whatever way you want)
but it's not particularly efficient, and still pretty tedious.

You can forego XmlSerializer and parse and generate XML yourself explicitly,
using XmlReader and XmlWriter or XmlDocument. This also gets tedious
quickly. .NET 3.5 introduces XElement, which is vastly more convenient, but
if you're stuck with .NET 2.0 this is not an option.

You can forego XmlSerializer and use BinaryFormatter, which doesn't have
XmlSerializer's restrictions. Obviously, this is only an option if you don't
really need XML, just a way to serialize your object.

 

[Marc Gravell]

You can forego XmlSerializer and use BinaryFormatter, which doesn't have

XmlSerializer's restrictions

On this point - DataContractSerializer (.NET 3.0) would be a happy
compromise - xml-based (although you have less control over the
layout), and it doesn't have the type-binding implications of
BinaryFormatter - i.e. you can have compatible definitions at client
and server when it isn't appropriate to share the actual assembly.

Marc

 

[Ethan Strauss]

Thanks. I will obviously have to do more reading, but at least I now know
what to look for.
Ethan

 

[Ondrej Svitek]

You can also throw an exception in the setter. It works fine, though there is a price you have to pay for this solution - an attempt to write to the property will be caught only at runtime instead of being a compile-time error.

private NumericSettings _numericSettings;

public NumericSettings NumericSettings
{
get { return _numericSettings; }
set { throw new NotSupportedException(); }
}