I have some serialized data (using BinaryFormatter), and wanting to deserialise it. However the deserialise method failed since the current assembly does not have the deleted field. I want to be able to reconstruct earlier assembly at run-time in order to deserialise the data. Appreciated any pointer. Thanks.
the technique is called versiontolerant serialization
see http://msdn.microsoft.com/en-us/library/ms229752.aspx
Related
I am encountering a really weird Exception on one of my application (later referenced as ApplicationB)
`Unable to find assembly 'MsgPack, Version=0.5.0.0, Culture=neutral, PublicKeyToken=a2625990d5dc0167'.`
Here is my scenario, on my ApplicationA I have serialized an object using MsgPack and store it into Redis using SE.Redis. Later on, I query this object and deserialize it (of course still using MsgPack). Once this is done, I am sending this object via a TCP/Componennt that serializes this same object using BinaryFormatter. On the other side, ie on ApplicationB, once the packet arrived, it is deserialized using BinaryFormatter and this is where I get the exception.
I don't have any control on the TCP/Component and the serializer it uses.
So why do I get this error on ApplicationB which should know any thing about MsgPack?
Just a thought I want to share, it seems that MsgPack create on the fly DataContract and when deserializing, it might applies some attributes on the object that conflict with the BinaryFormatter. Of course I am not sure about that.
But has anyone encountered this problem?
Cheers.
EDIT: I noticed that for member of type object, MsgPack adds a lot of members for defining the type store in the object member (like IsDictionary, IsList, etc.). Does it impact BinaryFormatter?
When using binary serialization, only the fully qualified type name and its data is serialized to a byte-array. The serializer on the other side wants to deserialize its data. It first reads the type name from the byte-array and tries to find and instanciate that type. That type must be somewhere in a DLL. So it looks for the given DLL (in your case MsgPack) but it cannot be found. Thus: Make sure the DLL MsgPack is located on both sides.
If it is not possible to to have the DLL on the other side, your could try to serialize the DLL itself and send it over to the other side. First deserialize the DLL, put it inside your bin folder or load it into memory, then deserialize the type with its data. But you must really, really, really make sure if you wanna do that. I wouldn't.
Have you ever considered communicating between AppA en AppB using WCF?
I need to generate or define new class based on deserialization serialized class. So I want to transfer class definition from server to client to have access to it's properties later.
Is it possible and how?
Proper way to do it would be to either expose a schema definition for your service for clients to consume & generate strongly type class definitions from that or provide a DLL with your DTO contract definitions (class/interface definitions) to the client.
If you chose neither of those approaches (no schema & no dll with interfaces) but still
want to generate a class definition, you can in an improper way generate .cs class definitions, from a sample data of the service (call the services couple of times and intercept the responses or use some http client). However this approach does not guarantee that you will get an accurate or/and complete generation. Basically you can go from:
XML->XSD->C# cs class file (or even XML to C# cs file directly)or JSON->C# class file
And deserializing object to dynamic especially when you don't own both the server & client code is pretty much the worst thing you can do. And this way you didn't transfer you class definition to the client. Deserializng to dynamic objects is actually no desrialization at all as matter of fact, it gives you a dictionary of strings with syntactical sugar to access them as properties at runtime with not compile time support which can be equal to a disaster. In short don't do it unless you own all the code (not that it's a good idea then either but maybe you could get by somehow)
One portable way to transfer the property definitions and the data itself is to use the JSON serializer.
You can deserialize into a dynamic object using JSON.Net
Deserialize json object into dynamic object using Json.net
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.
Im trying to store my data in an XML file using the XML Serialization. Question is, if my object has a collection member, can i serialize the collection as well?
This is how my objects work.
class Project{
List<Iteration>
}
class Iteration{
List<Job>
}
class Job{
some other attributes
}
So each project has a list of iterations, and each iteration has a list of projects. So essentially, Each project can have many iterations and each iteration can have many jobs.
If serialization is not possible, can anyone suggest to me another method to store my data?
thanks in advance.
I have used such a type of serialization before. If you have a simple application you can sometimes serialize your whole set of data from one root object (might be an antipattern somehow, but I know I have done it before).
This should work with the default XML serializer in the XML.Serialization namespace, but you need to make sure your classes are marked with the serializable attribute. I'm not sure if it is available on the compact framework though.
Have you considered using Json serialization instead? If you use something like Json.Net (available for Windows Phone 7), you should be able to serialize the entire object graph.
We are building application that stores objects to isolated storage using .NET runtime serialization.
Problems occur when we update application by adding some new properties to the classes of objects we are serializing. So we want to do some kind of versioning of the objects in isolated storage so we can check if they are obsolete before they are deserialized.
Any advice and ideas how to do this on best possible way?
What do you think about custom formatter implementing IFormatter interface and can it help instead of vesioning objects?
I wrote about this issue on MS forum more detailed here.
You COULD have a serialization in the serialization. First a wrapper class telling the version, and holding the inner true class.
This however feels a bit bad smelly..
Here are a few options (at in any particular order).
Name the file based on the version
Place the file in a directory based on a version
Create a wrapper object that contains metadata about each serialized object such as the version number.
Add a property to each object that contains the persisting application's version number
If its binary serialization, you could read the bytes directly, and determine the assembly version from this. Byte number 22 onwards contains information on the assembly and object type, so you could write something that would read this, and then determine if your objects are obsolete.
Marc Gravell was propose in comment great idea to use version-tolerant serializer.
It enables enough control of deserialization for us even to make obsolete objects reusable.
More on msdn
Thanks to all for suggestions.