DeSerialize xml string and ignore the first element within root - c#

I've got this XML data in string, structure can be seen as follows:
<Document>
<Contents>
<Content>
...
<Contents>
</Document>
So the structure is always like above, I made a class which exactly reflects the objects which will be identified as <Content>.
I wonder how I can deserialize the content in one go into a List of Content objects. Currently I try something as
XmlSerializer annotationSerializer = new XmlSerializer(
typeof(List<Content>),
new XmlRootAttribute("Document")
);
Of course this will not work as the first found element will be contents, how do I work around this? Do I require a certain attribute on the Content class?

You will need to use a root object here:
public class Document {
public List<Content> Contents {get;} = new List<Content>();
}
Now deserialize a Document and read .Contents. There are some scenarios where you can bypass the root object, but... not here, not conveniently.

Related

Constructor of a XmlSerializer serializing a List<T> throws an InvalidOperationException when used with XmlAttributeOverrides

Summary
When using the XmlSerializer class, serializing a List<T> (where T can be serialized with XmlSerializer without problems) using XmlAttributeOverrides such as this:
using xmls = System.Xml.Serialization;
...
xmls.XmlAttributeOverrides attributeOverrides = new xmls.XmlAttributeOverrides();
attributeOverrides.Add(typeof(T), new xmls.XmlAttributes()
{
XmlRoot = new xmls.XmlRootAttribute("foo")
});
attributeOverrides.Add(typeof(List<T>), new xmls.XmlAttributes()
{
XmlArray = new xmls.XmlArrayAttribute("foobar"),
XmlArrayItems = { new xmls.XmlArrayItemAttribute("foo") },
});
will throw the following InvalidOperationExcpetion at the inner-most exception:
System.InvalidOperationException: XmlRoot and XmlType attributes may not be specified for the type System.Collections.Generic.List`1[[T, programname, Version=versionnumber, Culture=neutral, PublicKeyToken=null]].
What I expect from the serializer
<texparams>
<texparam pname="TextureMinFilter" value="9729"/>
<texparam pname="TextureMagFilter" value="9729"/>
</texparams>
What I can sucessfully get at the moment
<ArrayOfTextureParameter xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<TextureParameter pname="TextureMinFilter" value="9729" />
<TextureParameter pname="TextureMagFilter" value="9728" />
</ArrayOfTextureParameter>
Background Info
I have been messing around with XML Serialization lately but have come across a problem. I am trying to serialize and deserialize some classes that wrap OpenGL textures.
In one of my classes (which I appropriately called BitmapTexture2d) I have a Bitmap field, which I wish to store in a Base64 element like so:
<bitmap64>
*base64goeshere*
</bitmap64>
Since I want to keep my code as neat as possible I decided to use the IXmlSerializable interface instead of creating a property which can convert a string and a Bitmap back and forth.
Later on in the process I decided to use the XmlSerializer class to generate the XML for a single field defined in Texture2d (which BitmapTexture2d is derived from) called Parameters (which is a List<TextureParameter> and TextureParameter is serializable by the XmlSerialization class). However this is how the serializer defaulted to serializing the List<TextureParameter>:
<ArrayOfTextureParameter xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<TextureParameter pname="TextureMinFilter" value="9729" />
<TextureParameter pname="TextureMagFilter" value="9728" />
</ArrayOfTextureParameter>
After seeing this, I decided to try and change the names of the nodes. After some research (where I landed at stackoverflow multiple times) I discovered the XmlAttributeOverrides class which can be passed to the constructor of XmlSerializer to add/override node names etc.
After writing out my code, the constructor for the sub-serializer started throwing an exception as described above. I have tried using an array which threw the same exception. I later though to serialize each element in the list one by one, but came to the conclusion that it was harder than I thought to achieve it that way. I posted this question somewhere else with no answer. And here I am...
Your problem is that you are trying to use overrides to attach [XmlArray] and [XmlArrayItem] to the type List<T>. However, as shown in the docs, [XmlArray] cannot be used in this manner:
[AttributeUsageAttribute(AttributeTargets.Property | AttributeTargets.Field
| AttributeTargets.Parameter | AttributeTargets.ReturnValue,
AllowMultiple = false)]
public class XmlArrayAttribute : Attribute
Notice there is no AttributeTargets.Class included? That means that [XmlArray] cannot be applied directly to a type and so attempting to do so via XML overrides rightly throws an exception.
But as to why that exception message states,
System.InvalidOperationException: XmlRoot and XmlType attributes may not be specified for the type System.Collections.Generic.List`1...
Er, well, that message is simply wrong. It would appear to be a minor bug in XmlSerializer. You could even report it to Microsoft if you want.
What you need to do instead is:
Override the [XmlRoot] attribute of List<T> to specify the desired name, in this case "texparams", AND
Override the [XmlType] attribute of T and set XmlTypeAttribute.TypeName to be the desired collection element name. In the absence of an [XmlArrayItem(name)] override this is what controls the element names of collections whose items are of type T.
Thus your code should look like:
static XmlSerializer MakeListSerializer<T>(string rootName, string elementName)
{
xmls.XmlAttributeOverrides attributeOverrides = new xmls.XmlAttributeOverrides();
attributeOverrides.Add(typeof(List<T>), new xmls.XmlAttributes()
{
XmlRoot = new xmls.XmlRootAttribute(rootName),
});
attributeOverrides.Add(typeof(T), new xmls.XmlAttributes()
{
XmlType = new xmls.XmlTypeAttribute(elementName),
});
return new XmlSerializer(typeof(List<T>), attributeOverrides);
}
Sample fiddle.
Note that when constructing an XmlSerializer using XmlAttributeOverrides you must cache the serializer for later reuse to avoid a severe memory leak, for reasons explained here.

rename property in xml schema class when serializing

I have an auto generated c# class file from an xml schema using the xsd generator tool.
There is a property in this class that i need to rename from "Balance" to "balance" when the xml file gets created.
As this is a generated class i need to update the created xml object on the fly before seralizing so cant just add an atrribute over the class property with the expected name.
I have accomplished the task of ignoring certain properties by using the XmlAttributes class so am sure there is something i could do along same lines for this
Can anyone point me in the direction of how to achieve this?
Thanks
I have managed to resolve my issue by using the following:
var overrides = new XmlAttributeOverrides();
overrides.Add(typeof(MyGeneratedCustomType), "Balance", new XmlAttributes { XmlAttribute = new XmlAttributeAttribute("balance") });
var serializer = new XmlSerializer(xmlFile.GetType(), overrides);
MyGeneratedCustomType is a type that appears in the generated xsd class which holds the property i needed to rename. Its an elegant solution as there is very minimal code required.
Assuming you need to deserialize from XML like this:
<root>
<Balance />
</root>
and then serialize to XML like this:
<root>
<balance />
</root>
You have two options here:
You could just create a second class that mirrors your auto-generated class in every way except for having [XmlElement("balance")] on the Balance property in the mirrored class. If the generated class is XsdGenerated and the mirrored class is CustomClass, create a constructor or override the =s operator to be able to populate the CustomClass with all the fields from XsdGenerated. When you serialize CustomClass, you should get the desired result. I think this is the preferable option.
Implement IXmlSerializable on XsdGenerated. Call base() in the ReadXml method, and just have the WriteXml method create the balance tag in lower case. Note that this option is probably more challenging to write/maintain and would limit your ability to serialize and deserialize - it'd be a one way operation, unless you created an even more complex mechanism to set whether ReadXml() and WriteXml() should treat balance with an upper or lower case b.

Upgrading the serializer for an XML file

I am making modifications to a legacy app which uses XmlSerializer to serialize/deserialize XML files into a class. The requirement is to change a certain property in the new app version, so that old files can be loaded like before, but an upgraded (more general) property should be persisted next time. The old property would then be ditched on next save.
To explain it a bit better, this is how the file looks:
<Data>
<ImportantAnalysisResults>
<ImportantAnalysisResult>...</ImportantAnalysisResult>
<ImportantAnalysisResult>...</ImportantAnalysisResult>
<ImportantAnalysisResult>...</ImportantAnalysisResult>
</ImportantAnalysisResults>
</Data>
New app version should load the file properly, and replace the element name with the new one on next save:
<Data>
<Results>
<Result>...</Result>
<Result>...</Result>
<Result>...</Result>
</Results>
</Data>
The <Data> element has many more properties, but this is one that needs to be changed. Also, ImportantAnalysisResult inherits from Result.
In my Data class, I tried doing something like this:
class Data
{
[Obsolete("Used for backward compatibility. Use Results instead.")]
[XmlArrayItem("ImportantAnalysisResult", typeof(Result))]
public List<Result> ImportantAnalysisResults
{
get { return _results; }
}
public List<Result> Results
{
get { return _results; }
}
}
But this would still save the old property back into the new file. What's the best way to make ImportantAnalysisResults disappear on next save?
Is there a way to simply "map" the old property to the new Results property while loading?
One way of doing this is using XmlAttributeOverrides. It helps you to overrides xml serialization. Hope it helps.
XmlAttributeOverrides xmlAttributeOverrides = new XmlAttributeOverrides();
//Add overrides to xmlAttributeOverrides, use sample from internet
XmlSerializer serializer = new XmlSerializer(typeof(Data), XmlAttributeOverrides);

XmlSerializer Serialize with a default XmlRoot

Is there anyway to add a XML Root Element or "Wrapper" in the XmlSerializer when I serialize an object?
The XML I am looking for would be something like this:
<Groups>
<Group method="ModifySubGroups" ID="1234" PIN="5678">
<SubGroup action="Delete" number="95">
<Name>Test</Name>
</SubGroup>
</Group>
</Groups>
I have two classes, Group and SubGroup. Group contains a generic list of SubGroups. It works great, but I don't have the XML Root "Groups". Using the two classes Group and SubGroup produces this:
<Group method="ModifySubGroups" ID="1234" PIN="5678">
<SubGroup action="Delete" number="95">
<Name>Test</Name>
</SubGroup>
</Group>
The only way I could get it to work was to create another class "Groups" that contained Group. So now I have three classes, Groups, Group, and SubGroup. Groups contains Group and Group contains SubGroup.
Any other ideas?
You don't normally use XML serialization to make XML pretty. If you need a root container element, then you need to have a root container object, and serialize that instead of Group object.
You can however serialize an array of Group object
void Main()
{
var g = new Group();
g.SubGroups.Add(new SubGroup {Name = "aaa"});
var ser = new XmlSerializer(typeof(Group[]), new XmlRootAttribute("Groups"));
using (var w = new StringWriter())
{
ser.Serialize(w, new Group[] {g});
w.ToString().Dump();
}
}
public class Group
{
[XmlElement("SubGroup")]
public List<SubGroup> SubGroups = new List<SubGroup>();
}
public class SubGroup
{
public string Name;
}
Naturally this means that deserialize code needs to either magically know that there is always one and only one Group element or assume that there could be 0 or more. Honestly I don't see much point in doing this unless you actually want to serialize collection of groups. It would just add confusion.
EDIT: if you really want to comply to vendors schema you are starting from wrong point.
You do not need to implement classes like this at all, all you do instead is taking an vendors XSD and use xsd utility provided with Visual Studio to generate .net classes from your schema, you can also choose which way you want serialize objects - using XmlSerializer or DataContractSerializer ( which gives you better flexibility i would say )
NOTE : you can use some tools to generate xsd from your xml if you do not have one and do not know how to write it on yourself
You can use XmlRootAttribute in order to specify custom XML Root
Also when you serialize collection you can specify wrapper - see Array Serializing

Parsing an XML file -options?

I'm developing a system to pick up XML attachments from emails, via Exchange Web Services, and enter them into a DB, via a custom DAL object that I've created.
I've manage to extract the XML attachment and have it ready as a stream... they question is how to parse this stream and populate a DAL object.
I can create an XMLTextReader and iterate through each element. I don't see any problems with this other than that I suspect there is a much slicker way. The reader seems to treat the opening tag, the content of the tag and the closing tag as different elements (using reader.NodeType). I expected myValue to be considered one element rather than three. Like I said, I can get round this problem, but I'm sure there must be a better way.
I came across the idea of using an XML Serializer (completely new to me) but a quick look suggested that these can't handle ArrayLists and List (I'm using List).
Again, I'm new to LINQ, but LINQ-to-XML has also been mentioned, but examples I've seen seem rather complex - though that my simply be my lack of familiarity.
Basically, I don't want a cludged system, but I don't want to use any complicated technique with a learning curve, just because it's 'cool'.
What is the simplest and most effective way of translating this XML/Stream in to my DAL objects?
XML Sample:
<?xml version="1.0" encoding="UTF-8"?>
<enquiry>
<enquiryno>100001</enquiryno>
<companyname>myco</companyname>
<typeofbusiness>dunno</typeofbusiness>
<companyregno>ABC123</companyregno>
<postcode>12345</postcode>
<contactemail>me#example.com</contactemail>
<firstname>My</firstname>
<lastname>Name</lastname>
<vehicles>
<vehicle>
<vehiclereg>54321</vehiclereg>
<vehicletype>Car</vehicletype>
<vehiclemake>Ford</vehiclemake>
<cabtype>n/a</cabtype>
<powerbhp>130</powerbhp>
<registrationdate>01/01/2003</registrationdate>
</vehicle>
</vehicles>
</enquiry>
Update 1:
I'm trying to deserialize, based on Graham's example. I think I've set up the DAL for serialization, including specifying [XmlElement("whatever")] for each property. And I've tried to deserialize using the following:
SalesEnquiry enquiry = null;
XmlSerializer serializer = new XmlSerializer(typeof(SalesEnquiry));
enquiry = (SalesEnquiry)serializer.Deserialize(stream);
However, I get an exception:'There is an error in XML document (2, 2)'. The innerexception states {"<enquiry xmlns=''> was not expected."}
Conclusion (updated):
My previous problem was the fact that the element in the XML file (Enquiry) != the name of the class (SalesEnquiry). Rather than an [XmlElement] attribute for the class, we need an [XmlRoot] attribute instead. For completeness, if you want a property in your class to be ignored during serialization, you use the [XmlIgnore] attribute.
I've successfully serialized my object, and have now successfully taken the incoming XML and de-serialized it into a SalesEnquiry object.
This approach is far easier than manually parsing the XML. OK, there has been a steep learning curve, but it was worth it.
Thanks!
If your XML uses a schema (i.e. you're always going to know what elements appear, and where they appear in the tree), you could use XmlSerializer to create your objects. You'd just need some attributes on your classes to tell the serializer what XML elements or attributes they correspond to. Then you just load up your XML, create a new XmlSerializer with the type of the .NET object you want to create, and call the Deserialize method.
For example, you have a class like this:
[Serializable]
public class Person
{
[XmlElement("PersonName")]
public string Name { get; set; }
[XmlElement("PersonAge")]
public int Age { get; set; }
[XmlArrayItem("Child")]
public List<string> Children { get; set; }
}
And input XML like this (saved in a file for this example):
<?xml version="1.0"?>
<Person>
<PersonName>Bob</PersonName>
<PersonAge>35</PersonAge>
<Children>
<Child>Chris</Child>
<Child>Alice</Child>
</Children>
</Person>
Then you create a Person instance like this:
Person person = null;
XmlSerializer serializer = new XmlSerializer(typeof(Person));
using (FileStream fs = new FileStream(GetFileName(), FileMode.Open))
{
person = (Person)serializer.Deserialize(fs);
}
Update:
Based on your last update, I would guess that either you need to specify an XmlRoot attribute on the class that's acting as your root element (i.e. SalesEnquiry), or the XmlSerializer might be a bit confused that you're referencing an empty namespace in your XML (xmlns='' doesn't seem right).
XmlSerializer does support arrays & lists... as long as the contained type is serializable.
I have found Xsd2Code very helpful for this kind of thing: http://xsd2code.codeplex.com/
Basically, all you need to do is write an xsd file (an XML schema file) and specify a few command line switches. Xsd2Code will automatically generate a C# class file that contains all the classes and properties plus everything needed to handle the serialization. It's not a perfect solution as it doesn't support all aspects of XSD, but if your XML files are relatively simple collections of elements and attributes, it should be a nice short-cut for you.
There's another similar project on Codeplex called Linq to XSD (http://linqtoxsd.codeplex.com/), which was designed to enforce the entire XSD specification, but last time I checked, it was no longer being supported and not really ready for prime time. Thought it was worth a mention, though.

Categories