Is there any way to serialize/deserialize an object DataContractJsonSerializer as well as ISerializeable interface. as my requirement is I get JSon from a web service and deserialize it into a collections of objects say message. now I want to write all objects in the list to file.. is there any way please explain.
The DataContractJsonSerialiazer uses the DataContract / DataMember attributes, and doesn't care about ISerializable. Nothing prevents you from adding both the DataContract attribute and implemented the ISerializable interface, though.
You could also use the System.Web.Script.Serialization.JavaScriptSerializer class instead, I believe that it respects ISerializable. It isn't very fast though, and doesn't support dates, so I would really not recommend it.
Are you sure you cannot just use the DataContract serializer? You can use that with a binary writer if you want to: http://msdn.microsoft.com/en-us/library/ms752244.aspx
Related
I have some data that is persisted in a database. The serialized content was originally written using the default NetDataContractSerializer with a DataContract attribute on the classes.
Now I want to move to using classes that implement IXmlSerializable to have more control over the serialized content and make it leaner and faster.
How will I be able to read the current content as well as store future content in the new way.
I have looked into ISurrogateSelector, but it doesn't seem to do the trick as the ISerializationSurrogate interface only supports getting and setting object data as the ISerializable interface, but no way to specify ReadXml and WriteXml as in IXmlSerializable interface. As I am reading in the stream, I don't have any information about the format other than the stream itself.
The deserialization must produce the same class instance regardless of the original serialization method.
I need to make a solution that uses .NET Framework 4.6
Does protobuf-net use BinaryFormatter or other formatter as an base serializer to serialize an object as byte[], and then write to stream?
add:
I use protobuf-net serialize data and want to deserialize in golang, is there any serializer can do the work in go?
Protobuf-net is a ground-up implementation of the "Protocol Buffers" serialization format, with an idiomatic .NET API. It has nothing to do with BinaryFormatter (although it can be used to create custom ISerializable implementations for use with BinaryFormatter, if you still play in that world).
If you want to use Protocol Buffers (protobuf) with Go, just pick one of the Go implementations from this list.
Most protobuf libraries are "contract first", meaning: you need a .proto schema; to get that from protobuf-net, use Serializer.GetProto<T>() for the T that you are using as a root type.
Note: if you are serializing DateTime or TimeSpan, it would be a good idea to make sure that you are using DataFormat.WellKnown on those members - it'll make it much easier to work in a cross-platform way with other libraries; but note that this is not a data-compatible change: it fundamentally changes how those values are stored, so : if you have existing data you'll need to think of a migration strategy.
On my own object I can add the metatag [Serializable] to make it serializable. Now I use a 3rd party library that I need to be serializable. I inspected the code and it should not be a problem. Is there a way to fix this without altering the 3rd party code?
My advice would be: serialize data, not implementation. The fact of the existence of a 3rd-party object is nothing to do with the data; that is an implementation detail. As such, I always offer the same advice: if serialization ever gets complex, the first thing to do is to introduce a separate DTO model that represents the data in isolation of the implementation, and just map the current state to that DTO. This allows you to handle implementation changes without impact on the storage, and allows otherwise non-serializable objects to be serialized.
Some serializers offer workarounds - for example with protobuf-net you can a: supply the serialization information for any type at runtime, and b: supply a "surrogate" to use automatically when it gets tricky, but - using a DTO model is simpler and easier to maintain.
Your use of [Serializable] suggests BinaryFormatter; in my opinion, this is almost never a good choice for any kind of storage, since BinaryFormatter relies on implementation details. It works nicely for passing data between two in-sync app-domains, though
If the types are public you should be able to use the XmlSerializer to do what you want.
There's more information on this here
Serializes and deserializes objects into and from XML documents. The
XmlSerializer enables you to control how objects are encoded into XML.
Exactly take your subclass and make it serializable.
[Serializable] public class Foo: Bar {}
Write an adapter or be prepared to do something more extreme like disassembling the assembly, injecting the serializable attribute and reassembling.
I'm writing a program that builds up a tree structure made up of classes that inherit from an abstract Node class. There are a number of different type of nodes built into my program. However, I also want to allow more advanced users to be able to reference my library and write their own derivations of Node. These plug-in libraries are then loaded when my app starts up through Assembly.Load(). Thus all the potential Node types used by my application will not be known until run time.
In addition, I want to be able to serialize and deserialize these trees to and from XML files. I have some experience with XMLSerializer, DataContractSerializer, and implementing IXmlSerializable. Typically, I go with DataContractSerializer as it usually requires less code then implementing IXmlSerializable, and can serialize private fields where XmlSerializer can not.
Yet with this project I also have to consider that other users will be creating classes that derive from my class, and will also have to add whatever code or attributes are required to serialize them as well.
Considering this are there reasons I should go with one serialization mechanism over another?
If the serialization and deserialization will only occur within your application, and if there is no requirement that anyone else be able to read the serialized data, then the serialization format doesn't impact the API: as far as a user of the API is concerned, you will serialize into an opaque file and deserialize from the same.
In this case, use DataContractSerializer, as it can serialize into binary if necessary.
In C#, if I want to serialize an instance with XmlSerializer, the object's type doesn't have to be marked with [Serializable] attribute. However, for other serialization approaches, such as DataContractSerializer, needs the class be marked as [Serializable] or [DataContract].
Is there any standard or pattern about serialization requirement?
This is because XmlSerializer only serializes public fields/properties. Other forms of serialization can serialize private data, which constitutes a potential security risk, so you have to "opt in" using an attribute.
Security isn't the only issue; simply, serialization only makes sense for certain classes. For example, it makes little snse to serialize a "connection". A connection string, sure, but the connection itself? nah. Likewise, anything that requires an unmanaged pointer/handle is not going to serialize very well. Nor are delegates.
Additionally, XmlSerializer and DataContractSerializer (by default) are tree serializers, not graph serializers - so any recursive links (like Parent) will cause it to break.
Marking the class with the serializer's preferred token is simply a way of saying "and it should make sense".
IIRC, both [XmlSerializer and [DataContractSerializer] used to be very rigid about demanding things like [Serializable], [DataContract] or [IXmlSerializable], but they have become a bit more liberal lately.
Right now there are really 3 forms of serialization in the .Net Framework.
XmlSerialization - By default works on public fields and properties. Can still be controlled via XmlElementAttribute, XmlAttributeAttribute, etc ...
BinarySerialization - Controlled by the SerializationAttribute. Deeply integrated into the CLR
WCF Seralization - DataContractAttribute, etc ...
There unfortunately is standard overall pattern for serialization. All 3 frameworks have different requirements and quirks.