<Serializable> vs. Inherits ISerializable

planoie · May 20th, 2005, 04:23 PM

A friend and I were having a discussion recently regarding the use of <Serializable> and "Inherits ISerializable" and where each is used. Up till then I didn't really understand what the <Serializable> class attribute was used for. He felt that we needed to mark our classes with the <Serializable> attribute in order for them to be serialized. This would certainly make sense. That serialization would cover the various places where objects can be serialized, notably web services and ASP.NET session state storage. I replied that I had written some web services that handled custom classes, but I'd never marked them with the attribute and they worked fine. Also, I have stored custom classes lacking the attribute in the ASP.NET session without problem. He suggested that storing in session when using InProc storage may work ok, but using SQLServer storage would not.

We continued to discuss at length while I set up a few tests. I created a simple custom class. I then put it thru several tests with and without the <Serializable> attribute:

A. Without <Serializable>
  1. Return in a webmethod: PASS
  2. Store in ASP.NET InProc session: PASS
  3. Store in ASP.NET SQLServer session: FAIL
B. With <Serializable>
  1. Return in a webmethod: PASS
  2. Store in ASP.NET InProc session: PASS
  3. Store in ASP.NET SQLServer session: PASS

The MSDN documentation says that all objects are serializable (<Serializable> attribute is applied to System.Object <s>implements ISerializable</s>). The CLR will throw an exception if any of a class' public properties are NOT serializable. So a custom class made up of most CLR types is serializable. The documentation goes on to report that the CLR will automatically serialize all the public properties of a class when needed (i.e. used in a webmethod or in SQLServer mode session state). It does suggest that if you build a custom class you may need to <s>inherit</s> implement ISerializable and provide your own serialization in order to capture values for non-public members that are required for accurate representation and reproduction of a custom class.

Despite all this, it seems that the way the CLR serializes is different between a webmethod and SQLServer session state. As shown in the test results, only when I attempted to store a custom class into SQLServer session state did I need to have the <Serializable> attribute on the class. However, because all classes are inherently serializable (because System.Object is) it seems there is little purpose for the <Serializable> attribute that I can see.

Does anyone have any insight as to how the serialization methods differ, what the specific differences are between <Serializable> and "<s>Inherits</s> Implements ISerializable" and/or what the real purpose is for the <Serializable> attribute?

-Peter

mehdi62b · May 21st, 2005, 12:27 PM

Quote:

quote:The MSDN documentation says that all objects are serializable (System.Object implements ISerializable).

System.Object doesn't implement ISerializable,System.Object has Serializable attribute..

and what is an attribute?it's something which located in the static partition of a class in modules,it is not something derivable in child classes!

yeah all objects could be serializable

Quote:

quote:what the specific differences are between <Serializable> and "Inherits ISerializable"..

can't get your meaning from "Inheriting ISerializable" if you meant implementing,it just controls the serialization process

Quote:

quote:..and/or what the real purpose is for the <Serializable> attribute?

some native .NET classes which dealing with serializing issue use the Serializable attribute,when they reflect on a class they should see that attribute otherwise they don't work

_____________
Mehdi.
software student.

Imar · May 21st, 2005, 01:00 PM

But that doesn't really explain the difference in behavior between serializing for a Web Service, and serializing for Session state, does it?

I find it very odd that you can't store an object in (Sql) Session state without the Serializable attribute, while at the same time, you can just pass this object around through a Web service.

Any idea why this works for a Web Service? Is there a difference in the serialization process for a Web Service as opposed to the Session state mechanism?

Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.

mehdi62b · May 21st, 2005, 03:07 PM

Quote:

quote:Is there a difference in the serialization process for a Web Service as opposed to the Session state mechanism?

absolutly,they are two complete different things,in webservices objects are serialized to SOAP format(XML)
not sure about ASP.NET and Sql Server but I think they serialized objects to binaryfiles(like a general serialization)

_____________
Mehdi.
software student.

Imar · May 22nd, 2005, 05:24 AM

Yes, obviously. However, that's just the output generated by the calling code. It's the Web Service technology that decides to generate XML rather than another format. But AFAICS, this has nothing to do with the object providing serialization information.

An object can be responsible for serializing itself, by applying the attribute or by implementing ISerializable (or by leaving both out all together).

The object itself isn't aware of the final output format (e.g. SOAP, some binary format, whatever), so all it can do is expose its public properties and their values, nothing more and nothing less.
Somehow, the Session State manager isn't able to serialize an object when the attribute isn't applied while serializing for a SOAP is successful.

So the question is: what does the State Manager do differently that it requires a serializable attribute on classes?

Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.
While typing this post, I was listening to: Lonesome Tonight by New Order (Track 7 from the album: Substance - Disc 2) What's This?

planoie · May 22nd, 2005, 07:30 AM

mehdi,

Thank you for pointing out my mistakes. I guess I'd typed inherits, implements and serializable so many times I got mixed up by the time I typed the post.

Quote:

quote:Originally posted by mehdi62b
some native .NET classes which dealing with serializing issue use the Serializable attribute,when they reflect on a class they should see that attribute otherwise they don't work

But my understanding is that all classes are inherently serializable in a default way (as proved by test case 1 above). If that is the case, what does adding the <Serializable> attribute really do? Is it possible that the 'Serialization' that we experience when a webservice method converts our class into XML is not the same Serialization that happens when ASP.NET converts the class to binary data for storage in SQL session state? And if that is the case, why call it Serialization? Why not call it XMLization (granted, XML is already a serial form)?

(An aside that's somewhat related to this topic: Is the 'Serialization' the new catch-word for 'Marshalling'? I still references to the term 'Marshal' when talking about COM interop.)

-Peter

mehdi62b · May 22nd, 2005, 02:41 PM

Quote:

quote:Originally posted by Imar
...So the question is: what does the State Manager do differently that it requires a serializable attribute on classes?

Ok,please look at definition for serializable attribute it's not something more than a simple attribute..and attributes are just used for controlling some process at runtime,they can't do anything more than it.

Quote:

quote:Originally posted by planoie

Quote:

my understanding is that all classes are inherently serializable in a default way (as proved by test case 1 above). If that is the case, what does adding the <Serializable> attribute really do?

take a look at this two examples

Code:

    public class MySerializer1
    {
        public MySerializer1(Type type)
        {
            if(!type.IsDefined(typeof(System.SerializableAttribute),false))
                throw new Exception
                    ("not serializable,please put the Serializable attribute!");
            //that is equal to type.IsSerializable
        }
        public void Serialize(object o)
        {
            //reflection stuff and saving it to every kind of files
            //also looking for implemented interfaces for controling
            //the output file and other stuff
        }
    }
    public class MySerializer2
    {
        public MySerializer2(Type type)
        {
            //no need for checking the attribute
        }
        public void Serialize(object o)
        {
            //reflection stuff and saving it to every kind of files
            //also looking for implemented interfaces for controling
            //the output file and other stuff
        }
    }

in your opinion which one is better?I think the number one,so the serializable attribute is not going to do something special,its just an attribute and could result in more robust codes,thats the way I think

we have some classes for serialization,

SoapFormatter in System.Runtime.Serialization.Formatters.Soap Namespace
BinaryFormatter in System.Runtime.Serialization.Formatters.Binary Namespace
XmlSerializer in System.Xml.Serialization Namespace

_____________
Mehdi.
software student.

Imar · May 27th, 2005, 02:37 AM

I see your point, but I am not sure I agree. Why would requiring the attribute result in more robust code?

In both cases, the serialization can take place without a problem, so what's the added benefit of the required attribute?

Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.

pgtips · May 27th, 2005, 04:25 AM

Hi Guys, I'm just starting to get into .NET (better late than never!) and I was reading about serialization just the other day. I got the impression that <Serializable()> was all to do with marshalling, specifically the ability for an object to be marshalled across process spaces or even across machine boundaries. basically if its marked as <Serializable()> then it can be marshalled by value, i.e. it can be all packed up, shipped across to another process or machine and recreated and used there. But if its not <Serializable()> then it can only be marshalled by reference, i.e it remains where it is and calls must be made cross-process or machine through a proxy.

It makes sense to me that you couldn't actually persist an object to SQL Server session state unless it was capable of being marshalled by value, and in order to MBV it must be marked as <Serializable()>

As has been said before, ISerializable looks to be just a way of defining exactly how your custom attributes/properties are to be serialized/deserialized.

Anyways, I'm very much a beginner in the .NET world so please let me know if I've got the wrong end of the stick.

rgds
Phil

Hal Levy · May 27th, 2005, 08:26 AM

Imar- could the IL be somehow different? Perhaps optimized for serialization when the attribute is used?

Hal Levy
I am here to help you, not do it for you.
That is, unless you hire me. I am looking for work.