17

Seeing as you can convert any document to a byte array and save it to disk, and then rebuild the file to its original form (as long as you have meta data for its filename etc.).

Why do you have to mark a class with [Serializable] etc? Is that just the same idea, "meta data" type information so when you cast the object to its class things are mapped properly?

Daniel
  • 8,133
  • 5
  • 36
  • 51
Blankman
  • 259,732
  • 324
  • 769
  • 1,199
  • For completeness, if you are storing the data (to disk etc) I **do not** recommend `BinaryFormatter` (which is the main one that cares about this). Most other serializers will do the job, but without biting you when you change the types. – Marc Gravell Apr 07 '10 at 19:25
  • However, the `BinaryFormatter` is by far the most powerful. It serializes fields and properties, it serializes the whole object including private fields, and it supports cyclic references, plus it bypasses object construction, thus does not require a public default constructor, none of which e.g. the `XmlSerializer` provides. If you want to change types, you'll have to cope with versioning. – mnemosyn Nov 27 '10 at 18:35
  • The opposite: [why-doesnt-the-xmlserializer-need-the-type-to-be-marked-serializable](http://stackoverflow.com/questions/392431/why-doesnt-the-xmlserializer-need-the-type-to-be-marked-serializable) – nawfal Jul 10 '14 at 09:58

6 Answers6

27

Binary serialization is pretty powerful, it can create an instance of a class without running the constructor and can set fields in your class that you declared private. Regular code can of course not do this. By applying the [Serializable] attribute, you explicitly give it the go-ahead to mess with your private parts. And you implicitly give that permission to only the BinaryFormatter class.

XML serialization doesn't need this kind of okay, it only serializes members that are public.

DataContractSerializer can serialize private members as well. It therefore needs an explicit okay again, now with the [DataContract] attribute.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • -1 until answer is corrected: Against popular belief, DataContractSerializer does not force you to mark a class [DataContract], it is a choice. When no attribute decorates the class, the serializer will by default infer a contract of all public read/write properties and fields. See MSDN: http://msdn.microsoft.com/en-us/library/ms733127%28v=vs.110%29.aspx – tsemer Oct 01 '13 at 14:09
  • 4
    The word "public" in that sentence appears to mystify you. – Hans Passant Oct 01 '13 at 14:20
  • Just in case it helps somebody, DataContractSerializer doesn't need [DataContract] attribute necessarily. [Serializable] will do (by which you also need not mark everything you need to serialize by [DataMember]). – nawfal Jul 10 '14 at 09:51
  • Fun fact: with the help of the [`FormatterServices`](https://msdn.microsoft.com/en-us/library/vstudio/System.Runtime.Serialization.FormatterServices(v=vs.100).aspx) class, you too can create uninitialized objects! Evil! :) – Vilx- Feb 13 '15 at 03:52
  • "Regular code can of course not do this." – Some Guy Mar 10 '22 at 15:59
  • Can't you just write a setter method to change private fields? – Some Guy Mar 10 '22 at 16:00
18

First off, you don't have to.

It is simply a marker interface that tells the serializer that the class is composed of items that it can serialize (which may or may not be true) and that is can use the default serialization.

The XMLSerializer has the additional requirement to have a zero parameter constructor to the class.

There are other serializers that use contracts for serialization (such as the DataContractSerializer) - they give you more control over serialization than simply marking a class as Serializable. You can also get more control by implementing the ISerializable interface.

Oded
  • 489,969
  • 99
  • 883
  • 1,009
  • 7
    The XmlSerializer does not require SerializableAttribute – Matthew Whited Apr 07 '10 at 19:11
  • @Oded: -1 until you edit your answer to show that the `XmlSerializer` doesn't care about `[Serializable]`. – John Saunders Apr 07 '10 at 19:15
  • 1
    @Matthew Whited, @John Saunders - thanks for the correction. Answer updated. – Oded Apr 07 '10 at 19:21
  • Just chiming in to recommend the chapter about serializing in "Framework Design Guidelines" by Krzysztof Cwalina and Brad Abrams which explains a bit when to use what from the standpoint of a Framework designer. – Michael Stum Apr 07 '10 at 19:39
  • You do have to. BinaryFormatter WON'T budge otherwise! I mean, it will throw on you... – Daniel Mošmondor Nov 27 '10 at 18:07
  • when it is not require decorate a class with serializable keyword then why peole do it...any special reason? – Thomas Jul 12 '13 at 14:41
  • @Thomas this thread is all about answering that question. See Hans's answer, clearer. Basically, it is not required to if all you care about is public members (for non-public you do need some serializable attribute). You also do need if you have some custom requirement (like excluding some field). – nawfal Jul 10 '14 at 10:05
2

It indicates to the serializer that you want that class to be serialized as you may not want all properties or classes to be serialized.

Chris
  • 26,744
  • 48
  • 193
  • 345
  • 2
    It can only be applied to types, not members. – Lasse V. Karlsen Apr 07 '10 at 19:10
  • 1
    I think this is a bit misleading - it sounds like if I have a serializable class A with a member B of a non-serializable type then member B will be ignored. In actual fact, serializing A will throw. – EMP Nov 22 '10 at 22:29
2

It's basically metadata that indicates that a class can be serialized, nothing more.

It is required by a lot of framework serializers, which refuse to deal with types not having this attribute applied to them.

Lasse V. Karlsen
  • 380,855
  • 102
  • 628
  • 825
2

Serialization can create security holes and may be plagued by versioning problems. On top of that, for some classes, the very idea of serialization is outright nonsense.

For details, see the excellent answers to Why Java needs Serializable interface?, especially this one, this one, and this one. They make the case that serialization should be a feature you have to explicitly opt into.

For a counterpoint, the accepted answer to that question makes the case that classes should be serializable by default.

Community
  • 1
  • 1
Jeff Sternal
  • 47,787
  • 8
  • 93
  • 120
0

I see it as a reminder that I will allow the class to be serialized. So you don't implicitly serialize something you shouldn't.

Don't know it that is designers' intention.

BTW, I just love BinaryFormatter and use it as much as I can. It handles pretty much of the stuff automatically (like rebuilding complex object graphs with recurring references spread throughout the graph).

Daniel Mošmondor
  • 19,718
  • 12
  • 58
  • 99