Is Microsoft serious about serialization?

I've been working through a serialization model have been stumbling over many semingly simple serialization problems that lead me to believe that Microsoft is not serious about serialization. There does not appear to be a unified model or methodology to the serialization within .Net.

For example, the latest problem I hit is that the System.Windows.Forms.Padding structure is not serializable. Why is it that Microsoft did not tag this seemingly simple structure with the Serializable attribute Is there some criteria Microsoft uses to decide what is serializable and what is not

Another example is the inconsistency of the formatters. They are so inconsitent that the objects MUST know what serializer will be used in order to take the appropriate actions for serialization and deserialization. For example, the XmlSerializer is NOT a Formatter object and only serializes and deserializes public fields. Whereas the SoapFormatter and BinaryFormatters serialize private members but do not adhere to the same event model.

These abiguities in the serialization models presented in .Net leaves the clinents of serialization guessing at the behavior of objects serialized with different formatters/serializers and what the Serializable attribute actually means.

In turn this confusion will lead to even more inconsistent serialization models by .Net clients as they take different paths to work their way through problems like simple structure serialization of system types not marked serializable.

Is Microsoft serious about serialization

- Ray

Answer this question

Is Microsoft serious about serialization?

Khin
Hi Ray,

There is. But I think thats based on pre-beta CTP.
Here is the link anyway:
http://winfx.msdn.microsoft.com/library/default.asp url=/library/en-us/indigo_con/html/503fae4b-014c-44df-a9c7-c76ec4ed4229.asp

Regards,
Vikram
WesHoward
Can Microsoft Serialization process be compatible with Java Serialization If microsoft could provide support for this it would be a great thing to used cross platform objects. So far microsoft serialization stream and java streams are incompatible.

Thanks
Rizwan
Mutantodon

Thank you. Can you open one for RuntimeMethodInfo not being deserializable as well (see http://forums.microsoft.com/msdn/ShowPost.aspx PostID=14217). I suspect the problem here is that RuntimeMethodInfo's aren't really ever created (except by the loader perhaps ) so there is no proper way to deserialize them through a constructor ([Serializable] and/or ISerializable).

That means a Surrogate would have to be used or the formatters are treating events specially. If a surrogate is being used, it's hidden from the user, and if I remember correctly, there is a bug that the builtin formatters do not use the returned value from ISerializionSurrogate.SetObjectData which in this case would be a reference to a different object (the looked up MethodInfo) and not the one passed in. That seems to imply that Soap and Binary formatters are treating events specially and doing the method lookups manually.

This isn't really a big deal, and if formatters need to treat events specially, so be it. The part that catches you off guard is when an object implements GetObjectData but not ctor(info, context). When references are dynamically bound in your application, objects that aren't serialization friendly wreak havoc on everything you do.

Thanks,
Ray Manning
Zesovich
We are very serious about serialization.

We have a whole team of folks working on it.

What you are encountering is the fact that we were too serious about serialization in v1 of the Framework -- so serious that we had two different teams working on serialization (the Remoting and ASMX teams)

This is the reason there is both the XmlSerializer and [Binary/Soap]Formatters.

We have merged these teams and will be releasing a common serialization framework with Indigo.

With that said, let's talk about how Microsoft decides if a type should be serializable.

In short, it is up to the team.

Our specific guidance that a type should only be serializable if there is a clear scenario for it.

Teams get to decided if there is such a scenario and react accordingly.

If there is some type you want to serialize, but it is not marked as such, you have two options: use a wrapper or use surrogate.

Hope this helps.
Ed__
I have tried also to design a formatter that just ignore the [Serializable] attribute but that's the path of hell. Indeed, as far I remember, the FormatterServices will throw exception for such non-tagged classes. And reimplementing FormatterServices is really tough.

Joannes
wookie
So there are two options: One designed for Remoting, where you specify both sender and receiver, and the other designed for raw XML in whatever form it happens to take. I need to create SOAP to be compatible with third parties, and apparently SoapFormatter is not a good choice for that. So where can I find good examples of how to do this with the XmlSerializer I need to create SOAP envelopes, and the examples I've seen so far don't do that.
A.I.V
So what should we be doing now in order to be well positioned to make the jump to Indigo Can you point me to any documentation to help me position myself

The guidance that a type should only be serializable if there is a clear scenario for it seems short sighted to me. It would seem to me that the better criteria would be to make the type serializable unless there is a clear reason not to. I understand there is a lot of work involved in making every type serializable but there are obvious cases where serialization is ignored on types where there is clear reason to have it. The Padding structure I already mentioned sure seems like a candidate for serialization, now I've run into BitVector32 not being serializable. Is anyone dog fooding serialization I find it hard to believe someone could look at such a simple type and say there is no clear scenario to serialize it and consciously decide it shouldn't be marked serializable. I suspect it wasn't even thought about.

I'd believe that leaving the choice up to the team is helping lead to confusion and and inconsistencies. Perhaps Indigo will fix this and I'd like to be well postioned for it so any guidance on how to position yourself for Indigo using .Net 2.0 would be appreciated.

Surrogates are one option that I'm working with. Wrappers aren't really practical because classes which use the underlying type cannot be serialized (unless you wrap those as well). Another option I'm considering is having my formatter ignore the [Serializable] attribute although I'm sure this will likely lead to hard to find bugs.

- Ray
Tony Lambert
Hi,

You can download the Beta Bits of Indigo which comes with documentation and go through it. It needs .NET Framework 2.0 Beta 2.
http://www.microsoft.com/downloads/details.aspx FamilyId=B789BC8D-4F25-4823-B6AA-C5EDF432D0C1&displaylang=en

Regards,
Vikram
snakegamer
I've opened Whidbey bugs against the appropriate feature teams to review why Padding and BitVector32 are not serializable.
sjw7
Thanks,

There wouldn't happen to be an online link to the Indigo documentation would there

- Ray
B.Young
Hi,

WebServices are commonly used for exchanging data in hetergenous environments. In case they do not suffice, there are various bridging solutions that allow you to overcome these issues:

1. JN Bridge - http://www.jnbridge.com/
2. J Integra - http://j-integra.intrinsyc.com/products/net/

I dont think Microsoft will try to support compatibility since both platforms and the way they evolve are different. Java has their own JCP etc which decide what gets implemented and Microsoft is on their own and decide what they want to have - so maintaining a compatibility between the two at the level of serialization may not happen.

Regards,
Vikram
Is Microsoft serious about serialization?

Answer this question