locked
Why must a type be marked as Serializable to be serializable??? RRS feed

  • Question

  • I think when we want to serialize a type, we mean it. Why the Framework forces us to attribute it as Serializable???

    In this way I have to add [Serializable] to the following simple class that contain ONLY simple privimite types, just to let it be serializable.


    class person
    {
        public string name;
        public uint age;
    }

     

    And more worse, if this class comes from a third party class library, I don't have a direct way to serialize its instances - I have to write custom converters or wrapper/mapper classes.


    Can someone wise enough to explain the reasons behind this design?

    Thanks.

    Friday, September 16, 2005 8:26 AM

Answers

  • Hi,

    The idea IMHO,  is to give more control to the class designer and let the class designer decide if he wants the class to be serializable or not.

    Regards,

    Vikram

    Friday, September 16, 2005 9:40 AM
    Moderator
  • Hi,

    Thats another way of looking at it - and yes it could have been implemented that way as well.

    You need to bear in mind that the CLR and the .NET Framework are defined and built by people who are experts in these domains - and they in many cases ensure that certain best practices are forced on end users who consume the framework.

    In my opinion, having an object travel across the wire is an expensive operation and needs to be thought out carefully. If every class was by default serializable people would probably take for granted as to what all they want to send on the wire since its possible to send anything on the wire as everything is serializable. This may not be good for performance etc.


    Regards,
    Vikram
    Sunday, September 18, 2005 10:40 AM
    Moderator
  • No, [Serializable] is a double-edged sword. Think of it as the ultimate mean to read all private fields of any class. One of the purpose of .Net is to enable the design of secure applications. Making [Serializable] implicit would be a very dangerous approach in term of security.

    Think of

    public class User
    {
        public string Name;
        private string Password;
    }

     


    Joannes
    Monday, September 19, 2005 8:07 AM

All replies

  • Hi,

    The idea IMHO,  is to give more control to the class designer and let the class designer decide if he wants the class to be serializable or not.

    Regards,

    Vikram

    Friday, September 16, 2005 9:40 AM
    Moderator
  • Then why not make this rule - all types are serializable by default and the class designer still have the chance to use NotSerialized attribute to apply to those properties that he does not want to serialize.

    I don't think current design benefits designers more than the one I have in mind.

    Friday, September 16, 2005 11:10 AM
  • Hi,

    Thats another way of looking at it - and yes it could have been implemented that way as well.

    You need to bear in mind that the CLR and the .NET Framework are defined and built by people who are experts in these domains - and they in many cases ensure that certain best practices are forced on end users who consume the framework.

    In my opinion, having an object travel across the wire is an expensive operation and needs to be thought out carefully. If every class was by default serializable people would probably take for granted as to what all they want to send on the wire since its possible to send anything on the wire as everything is serializable. This may not be good for performance etc.


    Regards,
    Vikram
    Sunday, September 18, 2005 10:40 AM
    Moderator
  • No, [Serializable] is a double-edged sword. Think of it as the ultimate mean to read all private fields of any class. One of the purpose of .Net is to enable the design of secure applications. Making [Serializable] implicit would be a very dangerous approach in term of security.

    Think of

    public class User
    {
        public string Name;
        private string Password;
    }

     


    Joannes
    Monday, September 19, 2005 8:07 AM
  • Exactly it would be like building all cars without doors(and locks on themBig Smile) . If you wanted your car to be secure you would have to buy them seperately as accessories, ok its an exxagerated example.
    But carrying this forward...we even have IIS 6 having as few features enabled by default as possible as against IIS 5, because enable a feature by default also means securing it, which does not always happen by defaultSmile.

    Wednesday, September 21, 2005 11:37 AM
  • Making all types serializable by default is probably a bad idea. I haven't checked, but I expect that type-specific code is added when a class is marked serializable so that it can be serialized; there may also be compile-time checks that are performed on serializable types - which would slow compiles if it were done all the time...
    Sunday, January 1, 2006 12:45 AM
  • Perfect. So, as a newbie to Enterprise Application Blocks, I need some help with [serializable];  I am getting an error because I am inheriting all of my entities from a base class provided by a third party.  Because it is not marked as serializable, I'm getting an error during run time.  Please tell me how to encapsulate a simple class like the one in your post so that I can take care of this.
    Thursday, October 26, 2006 10:07 PM
  • Joannes,

    How does not making a Class as Serializable enables security?

    You can still use Reflection to access private members???

    Thanks,

    Suresh.

    Monday, October 30, 2006 11:04 AM
  • Yes, it depends of the context.

    I was thinking to a remoting situation or a persistent storage situation that are the usual situations where serialization arise. In those situation, reflection has no effect.

    Also, even in "local scenario", it is possible to sandbox 3rd party  managed code and  prevent the execution of reflection mechanisms. In such situation, serialization would be a workaround of the sandboxing protections.

    Joannes
    Wednesday, November 1, 2006 10:25 AM