I've been scouring the web at MSDN and Google, for an answer to the following question.
How do I serialize a collection that is named as follows in c#?
<foocollection>
<fooitem1></fooitem1>
<fooitem2></fooitem2>
...
</foocollection>
I saw that you can do this in DataContract:
[CollectionDataContract(Name="foocollection", ItemName = "fooitem")]
public class FooCollection<T> : List<T> {
public FooCollection(){}
public FooCollection(T[] items){
foreach(var i in items){
Add(i);
}
}
}
The serializer is the default XML serializer from ASP.NET Web API. This code assumes that the XML posted above is coming from the client.
I have successfully serialized the above as dynamic, but dynamic isn't going to be an acceptable solution.
How would I accomplish serialization successfully using any of the below namespaces, or others, with the caveat that I can serialize to the above class? I'm willing to add extra classes as necessary to make the above work just as long as I don't have to make a class for every item in the collection.
System.ComponentModel.DataAnnotations
System.Xml.Serialization
Thank you very much in advance.
Since You didn't mention what method of xml serialization you're using, it's hard to tell, but you probably should be using DataContractSerializer in order to enable DataContract attributes. To utilize CollectionDataContractAttribute you also should have collection class that you put said attribute to, like in this example
I am looking for suggestions on how to best attack my problem.
I have a web application that will utilize a database and XML file as its data source.
Updating the DB is no issue, dealing with the XML file is.
First understand the web app is a bypass to a current(and bad performing production system). So there is no flexibility there.
So in case of the XML file the following steps will need to be performed if a user adds/update/delete a field.
Pull XML file from linux server
Parse XML file into POCOs for the UI
Recreate the XML file from the POCOs with the modifications
Push XML file to the linux server
The only good thing in my favor is that I won't have very many users using this app at a given time.
I would highly recommend looking at the DataContractSerializer for your serialization needs. Your objects would have to follow the same format as the XML, but there is no reason that you can't make those objects your model. Here is an example of marking up a POCO to serialize automatically to and from XML:
[DataContract]
public class Account
{
[DataMember, XmlAttribute]
public string Name { get; set; }
[DataMember]
public double Balance { get; set; }
}
And then you use the serialization code like this:
string serializedAccount = null;
XmlSerializer serializer = new XmlSerializer(typeof(Account));
using(StringWriter writer = new StringWriter())
{
serializer.Serialize(writer, myAccountObject);
serializedAccount = writer.ToString();
}
// serializedAccount should look something like this:
//
// <Account Name="MyName">
// <Balance>100</Balance>
// </Account>
//
// Each of the DataMember and DataContract attributes allow you to override
// names so that you can make them lower case, or provide a more meaningful
// name in your POCO.
Account deserializedAccount = null;
using(StringReader reader = new StringReader(serializedAccount))
{
deserializedAccount = serializer.DeSerialize(reader) as Account;
}
A couple things to keep in mind:
DataContract is an opt in policy. Members are ignored unless you explicitly mark them as ignored.
If you want to explicitly mark a field or property as ignored, use the [IgnoreDataMember] attribute. It can be handy even just for documentation purposes.
Nothing in the serializer prevents you from implementing INotifyPropertyChanged so all your properties can be bindable (handy for WPF)
If your XML format is not what you want to use as a model for your UI, you still may need to map properties in one object to properties in another object. This is still orders of magnitude easier than hand writing the XML reading/writing code yourself.
NOTE: if your server implements a proper SOAP web API, then WCF can take the WSDL and generate the bindings to the API and the objects that need to be serialized. There's a bit more work involved if it's a REST API, but that's also supported.
I have the following situation. In my C# application, I have a class which i serialize using XmlSerializer. The class is pretty complex, and an object of my class gets saved on local disc as an application file, which can be opened later (classic save work and reopen work). My problems is that during the development, the class of the object which gets serialized might change. I would like to have a version system, which allows my app to realize that the saved xml it belongs to an older version but still can be opened. Old app versions can not open new xml versions as well.
For example:
class ComplexObject
{
public string settings1;
public string settings2;
}
I serialize object, send app in production.
Tomorrow my class became
class ComplexObject
{
public string settings1;
public string settings2;
public string settings3;
}
How will my new version of app open serialized objects of old class definitions as well as new class definition with no error on loading file to object (deserialization)
Any suggestions and basic samples are welcomed!
Thanks
It all depends on the choice of serializer. In the case of XmlSerializer this is fine and will just work; clients with the new value will load the new value; clients without will not. Sample:
var reader = XmlReader.Create(new StringReader(
#"<ComplexObject><foo>123</foo><bar>abc</bar></ComplexObject>"));
var ser = new XmlSerializer(typeof (ComplexObject));
var obj = (ComplexObject)ser.Deserialize(reader);
with:
public class ComplexObject
{
public string foo;
}
which works and loads foo but not bar.
Do not use BinaryFormatter for this - that leads to a world of hurt. If you want binary output, consider something like protobuf-net which is designed to be overtly accommodating with versioning.
Version-tolerant serialization
In short, you either mark fields as Optional (and fill them with default values) or implement deserialization constructor which will parse values as you want them.
I hope I understood your problem correctly. You're having a class serialized to a file. Then you change the class in memory (e.g you add another property). No you want to deserialize this class from the file. This is no problem as long as you only add new properties. They will be ignored by the deserializer. He creates a new instance of your class (that is the reason, why serializable classes have to have a default constructor) and tries to fill the properties he finds in the stream to derserialize. If you change property's type or remove a property, you won't be able to deserialize that.
One workaround for "remove properties" maybe to keep properties you intentionally wanted to remove and ignore those furthermore.
You can take a look at Version Tolerant Serialization explained in msdn
http://msdn.microsoft.com/en-us/library/ms229752%28v=vs.80%29.aspx
Track 1
You could create some if..else mechanism for a new version file opener which would try to open file from lowest possible version to higher.
Track 2
You could store version information in your files.
class ComplexObject
{
public string settings1;
public string settings2;
public string fileVersion;
}
Track 3
You could use different file extensions for different file versions.(like .doc, .docx)
I have some generated proxy classes, that contain properties with the XMLAttribute attribute, e.g.
[System.Xml.Serialization.XmlAttributeAttribute(Form=System.Xml.Schema.XmlSchemaForm.Qualified, Namespace="http://www.egem.nl/StUF/StUF0301")]
public Verwerkingssoort verwerkingssoort
{
get
{
return this.verwerkingssoortField;
}
set
{
this.verwerkingssoortField = value;
}
}
This and several other properties don't show up in the SOAP message however. The proxies were generated using svcutil.
As I'm writing this question I notice that the properties that do show up as attributes are strings, while this is an Enum (but I haven't done a thorough check, yet). Does somebody know if this is the problem, or what else it could be and what possible solutions there are?
Update:
After some more checking, I found that no Enums are included as attribute, but Strings and Bools work fine.
Update 2:
In a simple case an Enum as attribute is serialized just fine.
Update 3:
If I replace XmlAttributeAttribute(...) with XmlIgnoreAttribute() and add the following property:
[System.Xml.Serialization.XmlAttributeAttribute("verwerkingssoort")]
public string verwerkingssoortString
{
get
{
return this.verwerkingssoortField.ToString();
}
set
{
this.verwerkingssoortField = (Verwerkingssoort)System.Enum.Parse(typeof(Verwerkingssoort), value, true);
}
}
it works fine, but making changes like this throughout the generated code would be a rather Herculean task, and when the contract changes, I would need to do it all over again. So I'm still looking for a better solution.
Update 4:
It turns out that this problem is not limited to attributes. I just noticed that a property that should be serialized to an element is omitted as well. The same things apply: it is an Enum, and it works fine if I change it to a string.
Thanks, regards,
Miel.
Have you tried setting Type property of the XmlAttributeAttribute class to the type of your enum?
I'm facing a problem that I don't know how to solve and am hoping the community can help.
I'm writing an app that manages "Lead" objects. (These are sales leads.) One part of my program will import leads from a text file. Now, the text file contains lots of potential leads, some of which I will want to import and some of which I won't.
For ease of programming (and use), I'm parsing the text file into a List<Lead> object, and using a DataGridView to display the leads by setting the DataSource property of the DataGridView.
What I want to do is add a column to the grid, called "Import," with a checkbox that the user can check to indicate whether or not each lead should be imported.
My first thought is to derive a class from Lead:
public Class LeadWithImportCheckbox : Lead
{
bool bImport = false;
public bool Import
{
get { return bImport;}
set { bImport = value;}
}
}
However, the parsing engine returns a list of Lead objects. I can't downcast a Lead to a LeadWithImportCheckbox. This fails:
LeadWithImportCheckbox newLead = (LeadWithImportCheckbox)LeadFromParsingEngine;
This is an invalid cast.
The other option I see is to create a constructor for LeadWithImportCheckbox:
public LeadWithImportCheckbox(Lead newlead)
{
base.Property1 = newlead.Property1;
base.Property2 = newlead.Property2;
....
base.Property_n = newlead.Property_n;
}
This is problematic for two reasons. One, the Lead object has several dozen properties and writing this constructor is a PITA.
But worse, if I ever change the underlying structure of Lead, I need to remember to go back and change this constructor for LeadWithImportCheckbox. This is a danger to my code maintenance.
Is there a better way of accomplishing my goal?
or, to avoid the PITA aspect, use reflection... (try this...)
EDIT: use property, not Field as I had originally written...
public class NewLead : Lead
{
public bool Insert;
public NewLead(Lead lead, bool insert)
{
Insert = insert;
foreach (PropertyInfo pi in typeof(Lead).GetProperties())
GetType().GetProperty(pi.Name).SetValue
(this, pi.GetValue(lead,null), null);
}
}
public class LeadListItem
{
public Lead Lead { get; set; }
public bool ShouldImport { get; set; }
}
i.e. don't copy the Lead object's contents, just store a reference to it in a new LeadListItem object, which adds extra info "outside" the original object.
If you want the properties of Lead to appear in the grid, there is almost certainly a way of doing that. Why not ask that question, instead of downvoting me for telling you the right answer to this question!
A couple options you might have missed:
You could update the Lead object itself to have an Import property (that defaults to false).
You could have your "ImportLead" object treat the Lead as payload (even make it generic, if you want), so you don't need the big constructor.
Build a new Lead object list or enumerable that only contains the objects you want to import in the first place.
You can only downcast, if the object to be downcast is really an object of that type.
An easier way to solve your problem would be to have a DisplayLead class, such as:
public class DisplayLead {
Lead lead;
bool bImport;
}
which would also help you separating stored data from their representation in a GUI.
What you want to do is display the checkbox column on your grid and not have it related at all to your Lead objects. You use the marked columns (and possible the original List) to build a new set of List which will be your import list.
Then handle whatever you wish to do with the newly created List.
Edit: One thing to be careful of when working with lists is the fact every class object is actually only a pointer to the class so if you work with the original list and do something like:
List<Lead> Importable = new List<Lead>();
for(int i=0, i++, i<viewGrid.Count)
if(viewGrid[i].CheckedColumn.Checked)
Importable.Add(OriginalList[i]);
That objects will exist in both lists and if you edit data of a Lead on either list both will be changed.
I cannot downcast to something it is not. If the object was instantiated as a Lead, then it can't be downcast to any derived class. If it were instantiated as a LeadWithImportCheckbox and then returned to your code as Lead, then you can downcast it.
Protip: Check type at runtime with is operator.
There are many ways to do this, but the "right" way pops out because of what you said, here:
For ease of programming (and use), I'm
parsing the text file into a
List object, and using a
DataGridView to display the leads by
setting the DataSource property of the
DataGridView.
What I want to do is add a column to
the grid, called "Import," with a
checkbox that the user can check to
indicate whether or not each lead
should be imported.
Your Lead object stands well on its own, and you want to attach some metadata to it -- you don't want to create another Lead classification (i.e. the LeadWithImportCheckbox class).
So, the best approach in your case is to have a class like so:
public class LeadInfo
{
private Lead lead;
private bool shouldImport;
public LeadInfo(Lead lead)
{
this.lead = lead;
this.ShouldImport = false;
}
public bool ShouldImport
{
get { return shouldImport; }
set { shouldImport = value; }
}
}
This will scale well when you want to add more metadata to your list, like if you want to send yourself email reminders about them every week.
I've seen the correct solution listed so many times I feel like a heel posting it again, but the best way to approach this is to write a wrapper for the Lead object that includes the import flag.
If the properties of the Lead object don't appear in the GridView because you're databinding to the object, then write passthrough properties that mirror the Lead properties on the wrapper object.
The issue is that you want something displayed to the user that isn't an inherent part of the data model. The answer is to wrap the data before presenting it to the user so you can control what they see without changing the underlying model.
If you're concerned that the Lead object will change so many times in the future that changes to the wrapper will be cumbersome, you could look into dynamic code generation based on the Lead object that will automatically generate a wrapper object with the same fields as the Lead object plus the import flag. Though frankly, that's a lot more work than you'll probably need for something as straightforward as this.
As a quick and dirty solution, you can create your 'checkbox' object as a different object that contains an instance of Lead.
public GridLead {
public bool Import { get; set; }
public Lead Lead { get; set; }
}
This way you can easily add more 'grid' properties to this object, while still always retaining a reference to the Lead details without hardcoding property cloning into it.
Recommend you try modifying (upgrading) your imported lead objects.
Try starting with the examples here...
If your Lead class had a copy constructor (e.g. "Lead(Lead otherLead)"), LeadWithImportCheckbox would inherit that and you could just call the base Lead constructor in the LeadWithImportCheckbox constructor - hence no need for LeadWithImportCheckbox to be aware of the details of Lead.