Even if you don't apply SerializableAttribute or ISerializable, every serializer that I know of does a good job of serializing objects anyway - So when is it a good idea, or a requirement, to use [Serializable] or ISerializable?
I understand [Serializable] and ISerializable are available whenever the default serialization behavior is undesired, such as, you want to exclude some public properties, or include some private ones. Is that the only situation where you need to, or should, use SerializableAttribute and ISerializable?
When you want to export a instance of object with setting in memory into a file and load again the next time you want to used just with the same settings and values before you saved.
This Link will explain you much better and is awesome the things you canto with it.
Related
i want to implement a general Memento-Pattern in C#. It is working fine but i use the Serializeable() Attribute to do a deep copy of a object. My implementation using generics so if someone use it he has to give his class as type.
Now the class from user must have the Attribute Serializeable() too. Are there any limitations for a class which using Serializeable()?
In fact:
Are there any performance problems?
Is it possible to use an interface?
Is it possible to use inerhitence?
Is it possible to use Auto-Properties?
I dont know how the Attribute works and so iam a bit scary of using this in such a global way.
regards
for small models that you are cloning in memory, not usually
irrelevent; when using [Serializable] you are typically using BinaryFormatter - which looks at the objects themselves; it doesn't matter what interfaces they implement - the interfaces are not used
yes, for the same reason - but all types in the model must be [Serializable]
yes, for the same reason; note : the default BinaryFormatter implementation is looking at fields - it won't even touch the properties
Personally, I try to advise against BinaryFormatter, but this is perhaps not an unreasonable use. However! Be careful that it is easy to suck extra objects into the model accidentally, must commonly through events. Note that it is a good idea to mark all events as non-serialized:
[field:NonSerialized]
public event EventHandler Something;
(or apply to the field directly if using explicit add/remove accessors)
Note also that any members like:
public object Tag {get;set;} // caller-defined
should also probably be [field:NonSerialized].
Personally, I'd prefer a different serializer, but: this will often work. I will say, though: try to avoid persisting the output of BinaryFormatter, as it is hard to guarantee compatibility between revisions of your code.
I dont know how the Attribute works
It does nothing at all except add an IL flag that says "by the way, consider this ok to be serialized"; actually, most serializers don't even look at this flag - but BinaryFormatter is one of the few that do look at this flag. The real code here is BinaryFormatter, which basically does:
have I seen this object before? if so, store the key only
what type is it? is it [Serializable]? store the type info
invent a new reference and store that as the identity
does it have a custom serializer? if so: use that
what fields does it have? access each in turn and store the name/value pair
I am trying to learn to use C# serialization as a way to save objects into files that can be reloaded back into objects.
A plain class like this that I tested
[Serializable()]
public class PlainClass
{
public string Name;
private int Age;
protected decimal Price;
}
Can be directly BinaryFormatter.Serialize() and BinaryFormatter.Deserialize() without errors. (by the way, the private and protected properties also get serialized although the docs say only public)
But the moment it implements ISerialization or inherit some class like Hashtable that implements ISerialization, the you-know-what deserialization constructor is required. The word or concept of "implement" becomes a misnomer because Hashtable does not actually implement that constructor.
Is there a way to fall back to the "auto" Serialization/Deserialzation provided only by the attribute? Or is there an easier way to write info.GetValue() for a hundred properties in a class?
There is a lot of confusion in your post:
by the way, the prive and protected properties also get serialized although the docs say only public)
I suspect you are confusing two different serializers; BinaryFormatter is and always has been documented as field-centric. It doesn't distinguish between public/private, and it never looks at properties: only fields. XmlSerializer, by contrast, only looks at public properties and fields.
The word or concept of "implement" becomes a misnomer because Hashtable does not actually implement that constructor.
Yes it does; it is a protected constructor:
protected Hashtable(SerializationInfo info, StreamingContext context)
{...}
If you inherit Hashtable you can chain to this constructor:
protected YourType(SerializationInfo info, StreamingContext context)
: base(info, context)
{ /* your extra data */ }
Note, however, that you probably shouldn't be using Hashtable much unless you are on .NET 1.1.
Is there a way to fall back to the "auto" Serialization/Deserialzation provided only by the attribute?
No; none.
Or is there an easier way to write info.GetValue() for a hundred properties in a class?
In the case of inherited data, you could chain the base-constructor or switch to encapsulation instead of inheritance - either avoids the need to worry about data other than your own.
Note, however, that I almost always guide against BinaryFormatter - it can be vexing, and is quirky with versioning. For every annoyance with BinaryFormatter, I use protobuf-net (I would, since I wrote it) - this generally makes serialization much more controlled (and more efficient), and includes an ISerializable hook if you really want to use BinaryFormatter (i.e. it can use BinaryFormatter as the wrapper, but with a protobuf-net payload).
Hashtable/Dictionary requires the implementation of the respective methods...
To work around that you would have to implement a separate class to hold the Dictionary data and provide an IList interface instead which in turn need not work on TKeyValuePair but with a separately implemented class with Key/Value (refer to http://blogs.msdn.com/b/adam/archive/2010/09/10/how-to-serialize-a-dictionary-or-hashtable-in-c.aspx)...
As you can see from the start of my explanation - this is nothing you would usually want to do...
There are better serialization solutions out there - see for a very good one http://code.google.com/p/protobuf-net/
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);
}
}
This is not properly a question but something more like a thought I had recently.
I'm taking XmlAttribute to XmlSerialize a class as an example: you can set attributes to a class to choose which properties should be serialized, but the same thing can be done quite easy by implementing a teorical interface IXmlSerializable (it does exist something similar, I don't remember) and by overloading a method "Serialize" for that class which just call Serialize on properties you want to serialize (this.myProp1.Serialize()), same for Deserialize
So what I'm basically saying: isn't Attribute method a bit redundant? (I like it actually, but I don't find it logically different from an interface)
Thanks for any answer, as I've said this is just a thought... hopefully someone will find it interesting
Update 1: Well I explained myself in a wrong way, what I'm asking is "why should I choose attribute instead of an Interface (or opposite)", not exactly this specific case (I took serialization because was the first thing that pop out in my mind), by the way thanks for your answer because they are very interesting
From the comments and downvote, maybe I should highlight my main point here: something that can save me hours of work (per type) and horrible code complexity is very much not redundant, but very, very welcome.
"quite easy"? OK; I'm pretty experienced at serialization, but the implementation for that is not what I call easy. Quite the contrary, in fact.
If you don't want to use attributes, there is an overload for XmlSerializer that allows you to configure it at runtime.
But I shudder whenever I hear "implement IXmlSerializable". The attribute approach is very quick and easy:
[XmlRoot("foo"), XmlType("foo")]
[XmlInclude(typeof(SuperFoo))]
public class Foo {
public string X {get;set;}
[XmlAttribute("y")]
public int? Y {get;set;}
[XmlElement("item")]
public List<string> Items {get;set;}
}
public class SuperFoo : Foo {}
I challenge you to write a robust implementation of IXmlSerializable for that very simple example in under 2 hours... and remember that every line you write is a line you have to maintain.
Well, from the best I can tell, they are logically different.
Implementing IXmlSerializable directly impacts the class itself, because you are adding an interface and one or more methods into the implementation of the class. In essence, You are making your own class directly responsibly for the it's serialization.
However, adding the XmlAttribute attributes does not directly impact the functionality of the class, instead you are just decorating it with attributes so that XmlSerializer can carry out the actual serialization functiohality. In this case, you are deferring the serialization to the XmlSerializer class, and providing just enough metadata about your class for XmlSerializer to do it's work.
This is why I prefer the latter attribute approach. When I'm writing a class, I want it to be serializable, but the last thing I care about is the specifics of the implementation, so I always start with thaqt approach and 99% of the time it works fine with very little work. However, if you did need more fine-grain control over the serialization, the implement the IXmlSerializable interface and write your own serialization code.
The programmatic method of implementing the interface may give a bit more control (and likely more speed), but is harder to create and maintain than the attribute method. I mostly use attributes.
You can select properties to (not) serialize with attributes. Implementation of interface is serialization by code.
I have data stored in an instance of a class which has been serialized with the .net BinaryFormatter. I now want to rename one of the fields in the class, but still be able to deserialize the old data.
One option is to implement ISerializable and deserialize all the the fields of the class manually. But this seems like a lot of work, especially if my class has lots of fields and I've only renamed a single field.
Is there a better way?
Craig suggests keeping a copy of the old class for deserialization, and copying values to the new class. I've seen this suggested elsewhere too - what advantage does this have over implementing ISerializable? As far as I can see, copying the class leaves me with 2 almost identical copies of the class plus I still have to copy all the values from the old class to the new class - which seems the same amount of work as implementing ISerializable with an almost duplicate class thrown into mix.
Two answers have mentioned Binders. I've successfully used a SerializationBinder to deserialize a class Bar which was Serialized as class Foo, but that's because the name of the class changed. Does SerializationBinder also help when you've renamed a field - say when int m_Left has been renamed to int m_Right?
Yes, this is the problem with field-based serializers. You can use either a custom Binder, or a "serialization surrogate" to avoid implementing ISerializable, but that is only a case-by-case fix.
I've discussed this topic (in the context of obfuscators, and auto-props) here. My advice is: don't use BinaryFormatter for persistance of data between versions... for that, look at contract-based serializers:
XmlSerializer
DataContractSerializer
or for binary, things like protobuf-net
None of this helps you today, but it might help you design around it in the future.
You could try having the old calss hang around for the sole purpose of rehydration and then just copy over the fields you need to the new class. Still kind of painful but should work.
I used SerializationBinder class for this before
http://msdn.microsoft.com/en-us/library/system.runtime.serialization.serializationbinder.aspx
it can be used for deserialization so you can remap old type to new one.
What if you just change the access modifier on that one property to private, and then have a public property with the new name that just basically wraps the old one. That way you should still be able to deserialize (I THINK) but anyone using this class won't know about the old name. Just a thought...