Scott, do you actively use default XmlSerializer? I was so up the wall with its inherited inefficiency (reflection + on the assembly gen) and bizzare limitations (no private data serlization?!), so i poked around internals a bit.

much to my surprise all it really boils down to is to implementation of VERY simple IXmlSerilializable interface (kept undocumented by MS for some reason) by objects. just 3 methods: WriteXml, ReadXml, GetSchema (last one can simply return null). With just a little bit of extra work to maintain these methods through your hierarchy you get MUCH more efficient and faster xml serialization without ever creating XmlSerializer instance, as well as you get option to maintain backward compatibility with old object serialization formats! of course its no longer automatical through reflection, but i don't think its really automatical via XmlSerializer in first place due to all this extra attributes legwork and extra problems with non-typed arrays.

my current vote is very much against XmlSerlializer, i wonder what other people expirience is.

Scott,

This is amazing. I am somewhat shocked that this problem is still around. I guess when you develop a new language, with new objects, you still face the same issues, no matter how you crack open the cosmic egg.

Even though I have been 'away' from daily coding for the last two years, I have been programming applications for over 30 years (yikes!). I have not delved deeply into the .net class libs, however, I have been programming in an OO state of mind since 1987 with LISP, LISP derivatives, and c++. Indeed, I have struggled with this problem (in various programming languages) of rich UI applications and how to translate (serialize) UI objects between the application and the server since about 1985. It seems that everytime I learn a new language, I seem to be coding the same capabilities into the new languages that I have already developed in the old languages. I mean, how many times can you code something different and creative into an order entry screen or a contact database?

I have reviewed Anders document "A Javascript Serializer", and this solution seems to me like a brilliant and elegant (yet simple and obvious) fix for a problem that has been around for as long as web application developoment has been around.

My first reaction was why wasn't this in the .NET API's? And why use such the 'Javascript' language with all it's inherent weaknesses? Now you've got me going. I will need to look at the .NET xmlserializer class and see what the hullabaloo us all about.

Doesn't the .NET Framework (classes, methods, etc.) provide just such a capability? It seems to me that if you are Microsoft, and you wanted to be able to provide for your customers(i.e. developers) to develop rich (fat?) UI's for web applications you would have already created an 'intelligent' methodology in the form of a class for translating objects/attributes from controls to xml and back for server-side/client-side processing? Don't get me wrong, I think that .net is a fantastic step forward in programming paradigms, but am I missing something here? Probably. I guess that this just demonstrates that not all tools have everything you need. As programmers, we still get to be creative and we could extend the base xmlserializer class to meet our needs.

That said, I was quite excited that Anders came up with such an elegant and straight forward solution to the problem. IMHO, the real work, would be to write as much of his solution into an extened class of the the .net framework, and then get Microsoft to add it to the next release of the .NET Framework.

Regards,
David