Develop Reference

How to support object Serialization and Deserialization for changing class structure with .net?

I have an entity class which can change over period of time. As of now, I binary serialization to serialize an object of this class. But if I add a new property to the class, I can't deserialize a stream serialized earlier. I tried if I can use BSON with json.net.
I need to take care of these things:
Memory footprint of serialized data should be low
serialization and deserialization should be fast
Need to provide backward compatibility for data serialized with old entity class structure
One approach I considered is to convert the object to IDictionary before serializing it so that I can set default value to properties that are not matching while deserializing. While this works well, it involves additional step to convert the object to IDictionary.
Has anyone faced this situation? what are the approaches you use?

Actually binary serialization is very flexible. Of course, you can just add [Serializable] attribute to the class and forget about details, but you can also take the full control on serialization by implementing ISerializable interface/by adding methods/attributes which corresponds to the certain steps of serialization/deserialization lifecycle. Considering your question about structure changes, please take a look on the following article.

serialize and deserialize objects from different location

I have two separate programs that need to share information. This sharing will be done by one app placing an XML serialized object in a database, and the other app retrieving it on a different machine. The objects share the same variables but the properties and methods are different.
How exact do the classes have to match between the two programs?
Is the match line by line or just variable, property, and method names?
I ended up using the Newtonsoft.Json library instead of xml and used the <JsonObject(MemberSerialization.OptIn)> and JsonProperty() attributes to control what got serialized.

You did not specify which kind of serialization you were after.
The standard NET binary serializer is not well suited for data exchange between 2 different assemblies. When you go to deserialize, you'll get an an error similar to [Culture].[Assembly].[Version].SourceClass cannot be deserialized to [Culture].[Assembly].[Version].DestClass. This will happen even if the classes are identical.
There are several ways around this. A) Use the same service DLL on both sides to do the serializing B) trick it into deserializing by using an override to report a matching Culture-Assembly-Version-Class, but that seems dodgy or C) use XML serialization, but that makes for very wordy output, which is also readable.
For Binary Serialization, rather than the NET binary formatter, there is ProtoBuf-NET which is faster, produces much smaller output and uses nearly identical syntax.
How exact do the classes have to match between the two programs
ProtoBuf uses a numeric index rather than property name, so they shouldn't have to be too similar. Of course there has to be some similarity or the destination may not have a clue what the data represents. The code in the class can be quite different because it stays put.

Serialization stores only the data for an object - member variables, properties, etc. As long as the data types are compatible, it should work. You do not need a line by line match for the functions.

It all depends on the serializer you are using. Some require a perfect match, others tend to be more loosely coupled to the objects.
How exact do the classes have to match between the two programs?
Well, not at all. But they should be similar in some way because otherwise the serialization doesn't make sense.
Is the match line by line or variables and method names?
As, stated above: there must be some overlap. Usually the property names must be the same. But of course you can also provide a custom mapping.
Take a look at the Newtonsoft library, u can use it (for json) like this:
JsonConvert.DeserializeObject<IEnumerable<Unit>>(result);
It's independent of the object method that serialized the string.

How can I serialize objects that inherit built-in c# classes?

I'm trying to create a function that will save the current state of my application to a file, and another function to load a saved file. Currently, all the information is contained within a single object, which in turn refers to other objects. I recently heard that C# has some built-in classes that help you serialize and deserialize your objects, so I did a little research and learned about DataContracts, mostly from this page: http://msdn.microsoft.com/en-us/library/ms731073.aspx
Most of it works, except for the classes that implement built-in classes. For example, I have an object that inherits System.Windows.DependencyObject, and when I try to serialize it, it complains that my class inherits a class that does not have the DataContract attribute.
It makes sense to me why that would be a problem. When an object is being deserialized, its constructor is not called. If it inherits something that is not serializable, that might leave it in an invalid state.
I was wondering if this was possible: can I somehow tell the deserializer to call the base class's default constructor before deserializing my object? And then I would have to tell the serializer not to freak out.

Can you create a data transer object that has all the properties you want to store, then populate that object with data from the framework object? Mark it as serialized, fire up the serialization class of your choice - and now you have all the info you need. You just need to re-populate the appropriate class after deserialization.

You may want to look into using a binary serializer or xml serializer instead of a data contract serializer for this one. If you're saving it to a file and don't need the file human-readable binary serialization nearly always works.
See Binary Serialization, and in particular the Basic Serialization topic.
Also take a look at the XmlSerializer Class which will sometimes work where a DataContractSerializer doesn't.

Serialization with Json.NET

I'm building a Silverlight wp7 app in C#. I have objects that I want to convert to and from JSON. I'm using JSON.NET.
Several properties of these objects require a bit of logic to initialize. Is there some way to use a custom converter method? (One such property is a List of strings. The data is given as a single String, and in the constructor the class splits it into a list.)
Also, I'd rather have the properties be read only, but they have to be read-write for conversation (right?). That's kind of a pain.
Or am I stuck doing the conversion manually?

Writing a JsonConverter allows you to manually serialize/deserialize a type. You could write one for a List that will split the string when reading and concatenate it when writing JSON.

If you are calling for the objects through a web service, you can change the encoding of the web service response to return JSON.
http://blog.davebouwman.com/posting-data-to-aspnet-json-services-with-doj

Serializing Generic Classes

I have read around that serializing generic classes is not supported out of the box with XamlWriter.
First I would like to know why? What is harder about generic classes that makes them non-plug-and-play like all the other classes are.
Second, is there a framework that will allow me to serialize my generic class without much work. (My generic class is fairly involved.)

XamlWriter is hardly the standard serialization method (unless something changed and no one told me!). You haven't actually mentioned what kind of format you want to serialize into, but since you mentioned Xaml I will assume Xml.
For this you can use the DataContractSerializer. It shouldn't have any problems with generic types, and isn't very difficult to use at all. Just remember to markup your class with DataContract and DataMember attributes, just as if you were using WCF.