Serializing an arraylist in C# - c#

I have a class that contains a number of standard fields and an arraylist.
Is there any way to serialize the class using an XmlSerializer?
Attempts so far result in an error message saying:
Unhandled Exception: System.InvalidOperationException: There was an error
generating the XML document. ---> System.InvalidOperationException: The type
XMLSerialization.DataPoints was not expected. Use the XmlInclude or
SoapInclude attribute to specify types that are not known statically.
Some cut-down representations of the classes are shown below:
public class StationData
{
private DateTime _CollectionDate;
private string _StationID;
private ArrayList _PolledData;
public StationData()
{
}
public DateTime CollectionDate
{
get { return _CollectionDate; }
set { _CollectionDate = value; }
}
public string StationID
{
get { return _StationID; }
set { _StationID = value; }
}
[XmlInclude(typeof(DataPoints))]
public ArrayList PolledData
{
get { return _PolledData; }
set { _PolledData = value; }
}
}
public class DataPoints
{
private string _SubStationID;
private int _PointValue;
public DataPoints
{
}
public string SubStationID
{
get { return _SubStationID; }
set { _SubStationID = value; }
}
public int PointValue
{
get { return _PointValue; }
set { _PointValue = value; }
}
}

I have had success with the following:
[XmlArray("HasTypeSpecialisations")]
[XmlArrayItem("TypeObject", typeof(TypeObject), IsNullable = false)]
public List<TypeObject> TypeSpecialisations
This results in:
<HasTypeSpecialisations>
<TypeObject />
<TypeObject />
</HasTypeSpecialisations>
In your situation I would try something like:
[XmlArrayItem(typeof(DataPoints))]
public ArrayList PolledData
Based on this link http://msdn.microsoft.com/en-us/library/2baksw0z(VS.85).aspx you should also be able to use this
[XmlElement(Type = typeof(DataPoints))]
public ArrayList PolledData

The XmlSerializer generates some code at runtime to serialize your class. It is necessary for this class to know all types that can occur.
The ArrayList does not give this information, but you can give it by using a XmlInclude attribute on the property that returns the ArrayList.
[XmlInclude(typeof(DataPoints))]
public ArrayList Points {
...
}
You could also use the generic List<> class.

I think you could get around this by using a generic list (List<>) instead of an ArrayList, however, I'm going to assume you can't use generics for one reason or another.
You need to tell the compiler what type is contained in the ArrayList so it can serialize it since all it knows it that it contains objects.
Add this above your property and it should clear it up.
[System.Xml.Serialization.XmlInclude(typeof(XMLSerialization.DataPoints))]
Of course, replace XMLSerialization.DataPoints with whatever class is contained in the ArrayList.

Take a look at this article which describes the basic problem you are having and a solution around it (Like using the XmlInclude attribute). Basically what that says is that the serializer encountered a type it doesn't know how to serialize. If you post some code it would also help greatly.

The method I always used to serialize lists was to convert them to Arrays (which has the necessary type information). I admit this is a bit dirty, but if you can't get a proper list to serialize, this will work.

Related

C# - add attribute like '.Length' to custom class

I've playing around with a class that acts as a public interface for a private List<T> attribute. I noticed that the List<> class has an attribute Length that tells you how many elements it contains.
This is an attribute you cannot alter, and on the intellisense appears with an image of a spanner next to it. It is not a method as it does not require () after coding the name.
I've seen attributes of this type before, but never used them in my own classes. Does anybody have any idea how I can replicate Length in my custom class?
Thanks,
Mark
It's a property with no setter. If you're wrapping a List<T> you can just use it's Count as your own:
public int Count {get {return _myPrivateList.Count; } }
If you're using C# 6, you can use this:
public int Count => _myPrivateList.Count;
If you currently have a class that contains a List, then you can take advantage of the Count property already present on it by exposing a property that simply uses that :
public class YourExampleList<T>
{
// Example of your inner list
private List<T> _list { get; set; }
// Use the Count property to expose a public "Length" equivalent
public int Length { get { return _list.Count; } }
}
This is actually not a method, but a property.
So you could have define in your class
private List<string> myList = new List<string>();
public int NumberOfElements
{
get { return this.myList.Count; }
}
A normal property would be defined such as
public bool ColumnNames { get; set; }
List<T> myList = new List<T>();
Now you can create your own implementation on your custom class. Something like:
public int Length {get {return myList.Count; }}
I must admit that your question is a bit vague. It sounds like you want know how to create a read only attribute / property. This can be achieved by creating a property wrapper for a private field member of your class as follow:
class MyCustomClass
{
private int _length;
public int Length
{
get { return _length; }
}
}
Say for example you have a class like this:
public class MyClass
{
private string _str;
public MyClass()
{
_str = "Sample String";
}
public int Length
{
get
{
return _str.Length;
}
}
}
This is what's happening:
We're declaring a private field at the start of the class named _str.
In the constructor we're then assigning it a value of "Sample String".
After the constructor we're then declaring the public attribute Length of type int, and only giving it a get accessor. Like your example, this only allows the value to be read, and not set.
Within the get we then tell it to return the value of _str's length.
Using code similar to this you can implement a Length attribute for any custom class.

unable to create two property with same name in C#

I have created two properties with same name but the data type is different.
I am getting this error:
The type 'Fields' already contains a definition for 'Subject'
Is it possible to overcome this issue?
public String Subject
{
get { return this.subject; }
set { this.subject = value; }
}
public AppSettings Subject
{
get {
return this.subjectObj; }
set {
this.subjectObj = value; }
}
No, it's not possible. You would not be able to tell these properties apart when using them. How would you know which property is set in this case?
someInstance.Subject = null;
The official documentation on class members states:
The name of a constant, field, property, event, or type must differ
from the names of all other members declared in the same class.
Possible solution:
Your naming suggests that you may want to create another class Subject with at least two properties. (Without more context, I can't say if this is appropriate.)
public class Subject
{
public string Name { get; set; }
public AppSettings Settings { get; set; }
}
This new class could be used in the original class:
public OriginalClass
{
public Subject subject { get; set; }
}
No, you can't overcome that. Imagine you're doing this line:
object myValue = MyClassInstance.Subject;
How would it know how to tell them apart? It's better to give them a more appropriate name:
public String Subject
{
get { return this.subject; }
set { this.subject = value; }
}
public AppSettings Settings
{
get { return this.subjectObj; }
set { this.subjectObj = value; }
}
No you cannot create that. The C# 4 spec, section 10.2:and the standards does not allow you do that
The names of constants, fields, properties, events, or types must
differ from the names of all other members declared in the same class.
On a side note you can refer this thread: Is there a way to use a property with same name but is of different type in derived class?
Most of the answers seem to put forth the reasoning that polymorphism is not allowed in Properties due to something like:
How would you resolve this:
MyObject.MyProperty = null;
Well that's essentially the same as:
MyObject.set_Property(null);
Where set_Property is a method like:
void set_Property(String name) { ... }
void set_Property(AppSettings settings) { ... }
This is legal in C#
So MyObject.MyProperty = null; can be resolved as:
MyObject.set_MyPropert(null);
The compiler will report an Error in the line where the call is made, since it could use both overloads.
But MyObject.set_MyProperty(string.Empty);
is legal all together.
The reason why C# disallows polymorphism on Properties is the same as why it disallows different return types of functions with the same name.
Illigeal:
String get_Property() { return ...; }
AppSettings get_Property() { return ...; }
Now if you do var value = get_Property(); the compiler can not decide which overload to use.
So in principle set only properties could be overloaded. The problem arises when you introduce a getter.
I guess for convenience and consistency reasons the standard disallows polymorphism on properties entirely.
Also because in the language context Properties are not really considered as methods.

C# Xml Deserialize plus design suggestions

In my project I need to build a generic deserializer that should be backward compatible.
Example: The XML looks like
<PolicyDef name = "sample" type="type1">
<Options ......>
</PolicyDef>
The "type" is enum - PolicyTypes
e.g
public Enum PolicyTypes
{
type1 = 0,
type2 = 1
}
The PolicyDef class is defined as
[XmlRoot("PolicyDef")]
public class PolicyDef
{
private string policyName;
private PolicyTypes policyType;
public PolicyDefinition()
{
}
[XmlAttribute]
public string Name
{
get
{
return this.policyName;
}
set
{
this.policyName = value;
}
}
[XmlAttribute]
public PolicyTypes Type
{
get
{
return this.policyType;
}
set
{
this.policyType = value;
}
}
}
The Problem with this approach is that if later on I put any type other than type 1 or type 2, the XMLDeserializer will throw exception.
so if i have the xml like
<PolicyDef name = "sample" type="type_new">
<Options ......>
</PolicyDef>
The deserializer will throw error as type_new not valid.
I was wondering if there is a way to hook into the deserializer process to catch that and set a default value rather than throw error. Say if there is any invalid value, then I would set that to "type1"
Or am open to suggestions regarding how to handle this problem
Thanks and Regards
This is possibly a duplicate of C# XML Deserialization W/ Default Values
Unfortunately it seems there is no way to fall back on default enum values during deserialisation. It will require slightly more work, but if you follow the linked example and implement IXmlSerializable in your PolicyDef class, you'll be able to implement the ReadXml method in a similar way (reflecting each of the properties using a try/catch block in order to check for a default value).
Hope that helps!
Thanks Chris for the suggestion, but I don't want end up writing the complete parsing code which could be messy if the XML and corresponding class is huge and complex. I anyway used a different approach.
I changed all the enum fields to string. In this case there would be no parsing error and then expose another property that would return the parsed value as enum and if the parsing fails, then return default enum value. E.g
private string policyName;
[XmlAttribute("Type")]
public string Type
{
private get
{
return this.policyType;
}
set
{
this.policyType = value;
try
{
this.PolicyType = (PolicyTypes)Enum.Parse(typeof(PolicyTypes), this.policyType);
}
catch(Exception)
{
this.PolicyType = PolicyTypes.DefaultPolicy;
}
}
}
public PolicyTypes PolicyType
{
get;
private set;
}
And use the class property to access the value rather than the xml attribute field.

C# XmlSerializer: keep the value, override the element label

I am currently using a LINQ query to read an XML file e.g.
<MyObjects>
<MyObject>
<MyElement>some_text</MyElement>
<MyOtherElement>some_more_text</MyOtherElement>
</MyObject>
</MyObjects>
into a list of custom objects containing custom HistoryString properties. HistoryString contains 2 strings, a currentValue and a previousValue.
This all works great except when using XmlSerializer to write the custom objects back to an XML file, the output fairly obviously contains additional tags i.e.
<MyObjects>
<MyObject>
<MyElement>
<currentValue>some_text</currentValue>
<previousValue>some_text</previousValue>
</MyElement>
<MyOtherElement>
<currentValue>some_more_text</currentValue>
<previousValue>some_more_text</previousValue>
</MyOtherElement>
</MyObject>
</MyObjects>
Q: What would be the neatest and/or most efficient way of reading and writing XML in the same format, based on this fundamental difference?
Some initial ideas:
1) Mark the previousValue property with [System.Xml.Serialization.XmlIgnore] then sweep through the XML string that is to be written removing all traces of <currentValue> and </currentValue>
2) Open the existing file and manually make any updates/deletes/additions - this is surely more long winded.
3) Any way of having a HistoryString automatically resolve to its currentValue rather than serialize each of its properties, similar to how ToString() works?
I have done some research into this, including the useful MSDN articles here and here but I can't see any other attributes that would solve this problem, I am still unsure whether this is possible. Any ideas?
Here is another idea. If you define your class like so:
[Serializable]
public class MyObject
{
[XmlElement(ElementName = "MyElement")]
public string CurrentValueElement
{
get
{
return Element.CurrentValue;
}
set
{
Element = new MyElement
{
CurrentValue = value, PreviousValue = value
};
}
}
[XmlElement(ElementName = "MyOtherElement")]
public string CurrentValueOtherElement
{
get
{
return OtherElement.CurrentValue;
}
set {}
}
[XmlIgnore]
public MyElement Element { get; set; }
[XmlIgnore]
public MyElement OtherElement { get; set; }
}
Then, when the object is serialized, the output XML will look exactly like your example.
Also, if you extend the CurrentValueElement/CurrentValueOtherElement setter like this:
[XmlElement(ElementName = "MyElement")]
public string CurrentValueElement
{
get
{
return Element.CurrentValue;
}
set
{
Element = new MyElement
{
CurrentValue = value, PreviousValue = value
};
}
}
Then you'll be able to use the XmlSerializer to deserialize your objects directly without needing to resorting to LINQ.
Well why not serialize back using original schema and feeding into it the list of transformed objects from history using only current value?
e.g.
from h in HistoryEntryList
select new OriginalEntry{ field = h.field.current_value, ... };

XML serialisation won't write out lazy-evaluated property

Following on from a previous question, I am having trouble combining the Lazy<T> generic that was suggested with my XML Serialization.
Here is the functionality I am using for Lazy<T>:
public struct Lazy<T> where T : class, new()
{
private T _Value;
public bool HasValue
{
get
{
return (_Value != null);
}
}
public T Value
{
get
{
if (!HasValue)
_Value = new T();
return _Value;
}
}
}
Now the MSDN Docs say that it's fine to have an [XmlElement("ElementName")] on a property and it does indeed seem to be able to deserialize just fine. The problem comes when I am serializing an object. I am running the following piece of code:
class SomeClass
{
[XmlElement("ExternalElementName")]
public ComplexElementType InternalElementName
{
get { return _InternalElementName.Value; }
}
protected Lazy<ComplexElementType> _InternalElementName;
}
Elsewhere:
SomeClass someClass = new SomeClass();
someClass.InternalElementName.ComplexElementTypeChild = "some string";
// serialize...
The strange thing is, this works fine in the debugger but no element is output in the XML. Non Lazy<T> elements work fine. Any ideas?
The problem is that the property has no setter. Even if it would be possible to get the value to serialise it, it can't be deserialised as there is no way to put the value back in the new object.
By design, XML Serialization will only serialize public read/write properties, and public fields.
Not sure what the problem is (I have always found the XML serializer behaviour to be shifty), but why not use the Nullable<T> class? Don't re-invent the wheel :)

Categories

Resources