I have a couple of entity classes autogenerated by Linq2Sql. I want to have a possibility to serialize them using DataContractSerializer. But when I'm trying to do that I'm getting an exception because DataContractSerializer can't serialize delegates. As I need to serialize only data, I want to exclude delegates from serialization process. How can I do that?
I can't do that using attributes, because the classes are autogenerated.
LINQ2SQL auto-generated classes are not POCO. AFAIK, they even not marked with DataContract attributes and contains a lot of stuff, which will be a pain for DataContractSerializer.
Create your own DTOs and serialize them. This will be more efficient.
Related
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.
What are the pros and cons of using the following two JSON serialization methods:
System.Web.Script.Serialization
DataContractJsonSerializer
DataContractJsonSerializer
The primary purpose of the DataContractJsonSerializer is to be used with WCF, since one serialization is a big focus of WCF. Also, it is also better equipped to handle complex classes which have only certain properties available for serialization. This class is more strongly typed, has more knowledge about the type(s) it's handling and better error handling for badly-formed JSON.
.
JavaScriptSerializer
This class on the other hand is much better equipped for quick serialization, it's a more cowboy approach. There's less error checking and less control over what properties which are serialized.
Reference
I've seen many different ways to serialize objects in C# that I'm not sure which one to use and when.
In the current situation I'm serializing for exposure through WCF so I'm guessing the [DataContract] attribute is the way to go.
Currently I'm reading in some XML, then exposing the resulting object through WCF. So I am deserializing XML for which I have no access to the original classes (therefore I'm rebuilding the class and can implement serialization whichever way I want). Then it has to be serializable for the WCF.
But if [DataContract] is good for this case, then why wouldn't I use it all the time instead of ISerializable, or the [Serializable] attribute?
So a bit of two questions in one, which to use for this problem, and why are there different ways to serialize.
DataContract is a good place to start for basic serializing. But if you want to control exactly how the object is serialized use the ISerializable interface. Also, the data contract attribute does not get inherited, but the ISerializable will
ISerializable has been around since .net 1.1. DataContract was introduced in .net 3.0 to simplify serializing for most cases.
Using ISerializable, by implementing GetObjectData, you can customize the way an object is serialized/deserialized within the object's class without having to create a serializer
If you create a WCF service, I think you should stick to DataContract. One of its big advantages is the opt in (i.e. no bad surprises) mechanism.
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.
I've implemented a data access library that allows devs to mark up their derived classes with attributes to have them mapped directly to stored procedures. So far, so good. Now I'd like to provide a Serialize() method or override ToString(), and have the derived classes get free serialization into XML.
Where should I start? Will I have to use Reflection to do this?
XML Serialization using XmlSerializer
In the first instance, I would look at the XML Serialization in the .NET Framework that supports serialization of objects to and from XML using an XmlSerializer. There's also an article from Extreme XML on using this serialization framework.
The following links all provide examples of using this approach:
CodeProject article
Microsoft KB article
DotNetJohn - XML Serialization Using C#
ISerializable and SerializableAttribute
An alternative to this would be to use a formatter and the regular SerializableAttribute and ISerializable system of serialization. However, there is no built-in XML formatter for this framework other than the SoapFormatter, so you'd need to roll your own or find a third party/open source implementation.
Roll Your Own
Also, you could consider writing your own system using, for example, reflection to walk your object tree, serializing items according to their serialization visibility, which could be indicated by your own attributes or the existing DesignerSerializationVisibility attributes. The downside to this shown by most implementations is that it expects properties to be publicly read/write, so bear that in mind when evaluating existing custom solutions.
I would start by looking at XmlSerializer.
Hopefully you'll be able to end there too, since it already gives you this functionality :)
You should be able to use the XmlSerializer to perform the serialization of your class
XmlSerializer serializer = new XmlSerializer(this.GetType());
serializer.Serialize(stream, obj);