Deserialize property w/ setter but no getter in 2.0???

  • Thread starter Thread starter Peter Franks
  • Start date Start date
P

Peter Franks

Is it possible to deserialize a class that has a public property w/ a
setter, but no getter?

I'm not finding anything that would allow this --

Presuming that is is NOT possible, what are the best practices for
implementing versioning for changing properties?

Thanks
 
Keith said:
If you have the source code, you can tag it with [XmlIgnore]

Right, but that applies to the property.

Here is an example of what I want:

public class Data
{
string stringValue;
public string StringValue
{
set { stringValue = value; }
}
}

//...

XmlSerializer serializer = new XmlSerializer(typeof(Data));
XmlTextReader reader = new XmlTextReader("data.xml");
Data data = (Data)serializer.Deserialize(reader);


// Presume that data.xml is:

<?xml version="1.0" encoding="utf-8"?>
<Data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<StringValue>Peter</StringValue>
</Data>

----

With the above, after deserialization, data.stringValue will NOT contain
the value "Peter".

From what I've seen, the XmlSerializer will serialize/deserialize
properties that have both a getter and setter.

This seems to be a huge weakness to the serialization, as such a
requirement is purely arbitrary.

Anyone have any comments/suggestions/workarounds?
 
XmlSerializer serializes only public fields. Either you need to declare
stringValue as public memeber or have access to your private member via
public properties.



public class Data
{
public string stringValue;
public string StringValue
{
set { stringValue = value; }
}
}

This should work.



Peter Franks said:
Keith said:
If you have the source code, you can tag it with [XmlIgnore]

Right, but that applies to the property.

Here is an example of what I want:

public class Data
{
string stringValue;
public string StringValue
{
set { stringValue = value; }
}
}

//...

XmlSerializer serializer = new XmlSerializer(typeof(Data));
XmlTextReader reader = new XmlTextReader("data.xml");
Data data = (Data)serializer.Deserialize(reader);


// Presume that data.xml is:

<?xml version="1.0" encoding="utf-8"?>
<Data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<StringValue>Peter</StringValue>
</Data>

----

With the above, after deserialization, data.stringValue will NOT contain
the value "Peter".

From what I've seen, the XmlSerializer will serialize/deserialize
properties that have both a getter and setter.

This seems to be a huge weakness to the serialization, as such a
requirement is purely arbitrary.

Anyone have any comments/suggestions/workarounds?
 
Ujjwal said:
XmlSerializer serializes only public fields. Either you need to declare
stringValue as public memeber or have access to your private member via
public properties.



public class Data
{
public string stringValue;
public string StringValue
{
set { stringValue = value; }
}
}

This should work.

It may work, but it is forced specific (undesired) design constraints
because of an arbitrary and extremely poor design of the XmlSerializer
class.

Note to those that are considering using the framework serialization for
version-portable files -- DON'T!

:

Keith said:
If you have the source code, you can tag it with [XmlIgnore]

Right, but that applies to the property.

Here is an example of what I want:

public class Data
{
string stringValue;
public string StringValue
{
set { stringValue = value; }
}
}

//...

XmlSerializer serializer = new XmlSerializer(typeof(Data));
XmlTextReader reader = new XmlTextReader("data.xml");
Data data = (Data)serializer.Deserialize(reader);


// Presume that data.xml is:

<?xml version="1.0" encoding="utf-8"?>
<Data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<StringValue>Peter</StringValue>
</Data>

----

With the above, after deserialization, data.stringValue will NOT contain
the value "Peter".

From what I've seen, the XmlSerializer will serialize/deserialize
properties that have both a getter and setter.

This seems to be a huge weakness to the serialization, as such a
requirement is purely arbitrary.

Anyone have any comments/suggestions/workarounds?
 
I don't know how poorly designed XmlSerializer is. We have an option to
bypass their desing by implementing IXmlSerializable Interface. In this case
you can serialize what you want and how you want. I like IXmlSerializable
interface and find it very useful.

Peter Franks said:
Ujjwal said:
XmlSerializer serializes only public fields. Either you need to declare
stringValue as public memeber or have access to your private member via
public properties.



public class Data
{
public string stringValue;
public string StringValue
{
set { stringValue = value; }
}
}

This should work.

It may work, but it is forced specific (undesired) design constraints
because of an arbitrary and extremely poor design of the XmlSerializer
class.

Note to those that are considering using the framework serialization for
version-portable files -- DON'T!

:

Keith Patrick wrote:

If you have the source code, you can tag it with [XmlIgnore]

Right, but that applies to the property.

Here is an example of what I want:

public class Data
{
string stringValue;
public string StringValue
{
set { stringValue = value; }
}
}

//...

XmlSerializer serializer = new XmlSerializer(typeof(Data));
XmlTextReader reader = new XmlTextReader("data.xml");
Data data = (Data)serializer.Deserialize(reader);


// Presume that data.xml is:

<?xml version="1.0" encoding="utf-8"?>
<Data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<StringValue>Peter</StringValue>
</Data>

----

With the above, after deserialization, data.stringValue will NOT contain
the value "Peter".

From what I've seen, the XmlSerializer will serialize/deserialize
properties that have both a getter and setter.

This seems to be a huge weakness to the serialization, as such a
requirement is purely arbitrary.

Anyone have any comments/suggestions/workarounds?
 
Ujjwal said:
I don't know how poorly designed XmlSerializer is. We have an option to
bypass their desing by implementing IXmlSerializable Interface. In this case
you can serialize what you want and how you want. I like IXmlSerializable
interface and find it very useful.

Ok, I'll look into that interface a little more.

However, it seems to be overkill for what amounts to a problem due to
what appears to be an arbitrary design failure of the XmlSerializer in
that it won't serialize a public property unless it has both a getter
and a setter.

:

Ujjwal said:
XmlSerializer serializes only public fields. Either you need to declare
stringValue as public memeber or have access to your private member via
public properties.



public class Data
{
public string stringValue;
public string StringValue
{
set { stringValue = value; }
}
}

This should work.

It may work, but it is forced specific (undesired) design constraints
because of an arbitrary and extremely poor design of the XmlSerializer
class.

Note to those that are considering using the framework serialization for
version-portable files -- DON'T!


:



Keith Patrick wrote:


If you have the source code, you can tag it with [XmlIgnore]

Right, but that applies to the property.

Here is an example of what I want:

public class Data
{
string stringValue;
public string StringValue
{
set { stringValue = value; }
}
}

//...

XmlSerializer serializer = new XmlSerializer(typeof(Data));
XmlTextReader reader = new XmlTextReader("data.xml");
Data data = (Data)serializer.Deserialize(reader);


// Presume that data.xml is:

<?xml version="1.0" encoding="utf-8"?>
<Data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<StringValue>Peter</StringValue>
</Data>

----

With the above, after deserialization, data.stringValue will NOT contain
the value "Peter".

From what I've seen, the XmlSerializer will serialize/deserialize
properties that have both a getter and setter.

This seems to be a huge weakness to the serialization, as such a
requirement is purely arbitrary.

Anyone have any comments/suggestions/workarounds?
 
Back
Top