Is implementing ISerializable interface necessary when not implementing any custom serialization/deserialization

Question

I am looking at a class in a solution that implements the ISerializable interface. It has a GetObjectData method for serialization as required by t

Answer 1

I see, implementing ISerializable is not neccessary for this class.or you must add a constructor with signature (SerializationInfo information, StreamingContext context) : protected PersonName (SerializationInfo info, StreamingContext context){ this.NamePrefix = info.GetString("NamePrefix"); this.SurName = info.GetString("SurName"); this.GivenName = info.GetString("GivenName"); }

Answer 2

the class really doesn't need to implement the ISerializable interface in the first place. Is that correct?

Correct. Implementing ISerializable is when you need to do something other than the default serialization behavior. The [Serializable] attribute should be enough.

Answer 3

An signature constructor (SerializationInfo information, StreamingContext context) is required. for deserialization time.

Answer 4

You might as well always implment ISerializable. Yeah, it can be a lot of typing if you have a lot of objects, but the deserializer will break if you later introduce it. I think it is better for versioning objects instead of writing new ones and keeping old ones.

Answer 5

Implementing Iserializable gives a performance improvement because there is no need to use reflection to serialize the object

Answer 6

It's pretty pointless.

It could be justified if it had once implemented ISerializable for a better reason, and implementation changes meant that it was no longer as useful. It could be a breaking change to stop implementing it.

If they'd implemented it with an explicit implementation (void ISerializable.GetObjectData(SerializationInfo info, StreamingContext context) rather than public void GetObjectData(SerializationInfo info, StreamingContext context) and had the constructor that took SerializationInfo and StreamingContext private, then it'd be a less damaging change - still technically a breaking change but much less likely to actually break any real uses. This in itself is a reason for having that constructor private.

It must though be at least protected if the class isn't sealed, and derived classes must use it if they are to also be serialisable. In this case it's totally going to be a breaking change to stop using it as all derived classes would then be broken.

It would likewise be breaking change if you didn't implement it, and then started doing so, and had classes derived from it. This could be a justification for pre-empting the possibility, though to be honest I'd see that as a major failure of the YAGNI principle unless there was a very very good reason to suspect it would become useful. (Generally if you were going to add something that would make it necessary you could wrap whatever features required it in another class, implement it on that, and have a member of that type, so the existing class can still be serialised without it).

Edit: The "must" above is the "must" of "you must do this or there are bad implications" rather than the "must" of "you must do this or it won't compile". Of course, the former are worse than the latter because you can sometimes fail to do them.