My program creates xslt files and stores the information from custom classes there, this is done dynamically with attributes which mark the classes and properties I want to store in the xslt. This was quite easy because i just had to name the attribute like the property and fill the value with the object's toString() method.
Now I want to somehow reload that Information, create the same classes and fill the properties with those values. But how do i do that with e.g. Enums and other complex types if i don't know the type at compile time? Has to be some sort of parse method..
Any ideas?
If you just want to serialize your objects to XML and then desterilize them, and your objects contain interfaces, generic lists or other complex type you can use very useful serialization library http://www.codeproject.com/KB/XML/sharpserializer.aspx by Pawel Idzikowski.
It is really straight forward and can be very helpful in such cases.
Related
I have a Json schema and can use NJsonSchema.CodeGeneration.CSharp to create classes corresponding to it. So if I have json which conforms to the schema, I should be able to easily parse it into a collection of objects whose classes are the classes generated from the schema?
So how can I do this - parse json and get out C# class objects that correspond to the objects in the json (as define by the schema)?
As an example - if the schema defines a first object definition which is an array of a second object definition, then I would like to be able to parse it in such a way that the output is an instance of the class corresponding to the first object definition and it has a member which is a List of instances of the class corresponding to the second definition. It seems that the schema knows all the information required to do this, so it should be a single line - I appreciate I could do long-hand parsing (eg converting each item in the array) to achieve the same result.
I would think this would be a primary purpose of having C# classes generated from a schema, so what's the magic method I'm missing?
I'm also happy to write C# classes and generate a schema from that if it's a more workable solution.
I've used NJsonSchema but happy to use any other C# json schema and code generation technique that achieves the same end.
UPDATE: After discussion I've seen that if NJsonSchema is used to generate classes from the schema, the TypeScript version of those classes each have a fromJS method which sounds like what I want but they're missing from the C# version. I'm happy to use something other than NJsonSchema to generate classes from schema if it provides a solution.
I think I found the answer, which was a lot simpler than I had anticipated. It's simply to use something like:
var ob=JsonConvert.DeserializeObject<MyNamespace.Anonymous>(jsonString);
...where MyNamespace is the namespace of the generated C# classes, MyNamespace.Anonymous is the class corresponding to the root of the schema (default names from NJsonSchema), and jsonString the string to be parsed.
I thought the solution would need to be schema-aware, since it would need to know about all the classes created from the schema, but I guess it 'works that out' from reflecting on the Anonymous class it's given and where the properties of it are classes, reflecting on those and so on.
I was over-thinking the problem!
Does anyone know if there is an alternative to using attributes on C# properties to map to XML nodes when using XmlSerializer?
My issue is that I have an object called Article, with some properties (e.g. ID, Title, Body) and I do not want to add attributes directly to it (used elsewhere, etc, etc)...so I created a partial class and re-defined the properties and added the attributes there, but soon discovered that you cannot have duplicate properties in partial classes.
So I was wondering if anyone knew of any way that I could map the properties instead (in a similar fashion to n-hibernate, for example).
I'd appreciate any help.
There's a constructor of the XmlSerializer class that allows you to pass a XmlAttributeOverrides and thus alter the behavior at runtime.
Quote from the documentation:
The overrides parameter can be used to control how fields and
properties are encoded in XML. These settings override any attributes
that already exist on the objects. This can be useful when the source
code cannot be modified or multiple encodings are required for the
same classes.
You could implement IXmlSerializable directly. It requires some more code, but you will have full control without the need for attributes.
I'm wondering how to exclude/strip certain properties of given type(s) (or collections of those) from being serialized using Json.NET library?
I tried to write my own contract resolver (inheriting from DefaultContractResolver) with no luck.
I know that I could be done using DataAnnotations, decorating the excluded properties with ScriptIgnoreAttribute, but it's not applicable in my scenario. The objects serialized can be virtually anything, so I don't know which properties to exclude at design-time. I know only the types of properties that should not be serialized.
It looks like a rather simple task, but unfortunately I couldn't find a decent solution anywhere...
BTW - I'm not bound to Json.NET library - if it can easily be done with default/other .NET JSON serializers it'd be an equally good solution for me.
UPDATE
The properties has to be excluded before trying to serialize them. Why?
Basically, the types of objects I'm receiving and serializing can have dynamic properties of type inheriting from IDynamicMetaObjectProvider. I'm not going to describe all the details, but the DynamicMetaObject returned from GetMetaObject method of these objects doesn't have DynamicMetaObject.GetDynamicMemberNames method implemented (throws NotImplementedException...). Summarizing - the problem is those objects (I need to exclude) doesn't allow to enumerate their properties, what Json.NET serializer tries to do behind the scenes. I always end up with NotImplementedException being thrown.
I have tried both the WCF JSON serialization as well as the System.Web.Script.Serialization.JavaScriptSerializer. I have found if you want solid control of the serialization process and do not want to be bound by attributes and hacks to make things work, the JavaScriptSerializer is the way to go. It is included in the .NET stack and allows you to create and register JavaScriptConverter subclasses to perform custom serialization of types.
The only restriction I have found that may cause you a problem is that you cannot easily register a converter to convert all subclasses of Object (aka, one converter to rule them all). You really need to have knowledge of common base classes or preregister the set of types up front by scanning an assembly. However, property serialization is entirely left up to you, so you can decide using simple reflection which properties to serialize and how.
Plus, the default serialization is much much much better for JSON than the WCF approach. By default, all types are serializable without attributes, enums serialize by name, string-key dictionaries serialize as JSON objects, lists serialize as arrays, etc. But for obvious reasons, such as circular trees, even the default behavior needs assistance from time to time.
In my case, I was supporting a client-API that did not exactly match the server class structure, and we wanted a much simpler JSON syntax that was easy on the eyes, and the JavaScriptSerializer did the trick every time. Just let me know if you need some code samples to get started.
Create your own contract resolver, override the method that creates the properties for an object and then filter the results to only include those that you want.
Have you considered using the ShouldSerialize prefix property to exclude the property of your specific type at runtime?
public class Employee
{
public string Name { get; set; }
public Employee Manager { get; set; }
public bool ShouldSerializeManager()
{
return (Manager != this);
}
}
Is there a way in .Net 4 to easily deserialize a stream of mixed objects one by one? I can read to the start of the element for an object I want to deserialize using XmlTextReader.Read(), but have tried many ways to deserialize that specific object unsuccessfully.
The types I want to deserialize can be read as a list of those types without a problem using XmlSerializer, however I want to be able to mix them rather than having input files containing just lists of one object type.
e.g.
<Objects>
<TypeA>...</TypeA>
<TypeB>...</TypeB>
<TypeA>...</TypeA>
<TypeC>...</TypeC>
...
</Objects>
The ordering of the objects in would be random.
Many thanks for any pointers.
I've looked at XmlSerializer, DataContractSerializer and XElement, but could not get them to work for this (although I possibly didn't set those up correctly as I'm not very familiar with them).
You can do that with the XmlSerializer.
However, be careful with the following:
The array you are serializing/deserializing must be declared as an array of "object" (or the base object if all other types inherit from it)
Each type will have "xsi:type" attached to it
You must use [XmlInclude] to include all the type(s) you are ever going to need with the "root" object.
The need to [XmlInclude] all the object types mean that you're not going to be able to dynamically add types to the serialization. You'll need to add [XmlInclude]'s and recompile to include the new type(s).
Your XML, however, will become:
<Objects>
<TypeObj xsi:type="TypeA">...</TypeObj>
<TypeObj xsi:type="TypeB">...</TypeObj>
<TypeObj xsi:type="TypeA">...</TypeObj>
<TypeObj xsi:type="TypeC">...</TypeObj>
:
</Objects>
This is the most flexible and "normal" way of approach XML serialization of multiple types. However, if you need to keep your exact format, you can declare your class this way:
[XmlRoot("Objects")]
public class Objects
{
[XmlElement("TypeA")] public TypeA[] TypeAObjects;
[XmlElement("TypeB")] public TypeB[] TypeBObjects;
[XmlElement("TypeC")] public TypeC[] TypeCObjects;
:
}
[XmlElement] means that all the objects are jumbled up on the same level (different from XmlArray). They do not even have to be in order.
The pitfalls of doing this, however, is that if you want to add a new type, you'll have to modify the "Objects" class.
Not sure if this is helpful, but it might be an idea to take a look at how RestSharp does their deserialization. https://github.com/johnsheehan/RestSharp
Specifilcally Take a look at RestSharp/Deserializers/XmlDeserializer.cs
You would need to create an XmlSerializer for each type. How many types you have and how many times each would get used would determine if it's better to create a new XmlSerializer for each object as you process it, or store them in a Dictionary<string, XmlSerializer> to be reused. The XmlSerializer takes the type in its constructor, and then you can call the Deserialize method, passing it a StringReader that contains the XML string you read from your file. Hopefully that's enough to get you started, but if you need more help I can throw together some sample code ;)
Currently I'm using XmlSerializer to serialize and deserialize an object. The xml is generated in an undefined order which is understandable but makes it annoying when comparing versions of the object, since the order of properties is different each time. So for instance I can't use a normal diff tool to see any differences.
Is there an easy way to generate my xml in the same order every time, without writing the ReadXml and WriteXml methods myself? I have a lot of properties on the class, and add new ones every now and again, so would prefer to not have to write and then maintain that code.
(C# .net 2.0)
The XmlElement attribute has an order property. You can use that as a start.
If you need to find the diff in Xml files, you might want to take a look at this.
Decorate your properties with the XmlElementAttribute, setting the Order parameter.
ps: I don't believe the XML generated by the XmlSerializer is in an undefined order. It may be undocumented, but it is known. I believe that in the absence of Order attributes, the XmlSerializer serializes all public Properties, alpha-sorted by prop name, and then all public Fields, alpha-sorted by name.