xml serialization of IDictionary

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi everybody,

Can sombody explain to me why the dotnet framework does not automatically
serialize objects implementing IDictionary as array of DictionaryEntry?

I know how to work around this limitation, but having to write wrappers for
every class/property that implement IDictionary gets old really quick :)

Thanks,
Nadav
 
Hello Nadav,

Probably because that identity cant be preserved - keys of deserialiated
IDictionary wont match the original

NP> Hi everybody,
NP>
NP> Can sombody explain to me why the dotnet framework does not
NP> automatically serialize objects implementing IDictionary as array of
NP> DictionaryEntry?
NP>
NP> I know how to work around this limitation, but having to write
NP> wrappers for every class/property that implement IDictionary gets
NP> old really quick :)
NP>
NP> Thanks,
NP> Nadav
---
WBR, Michael Nemtsev [C# MVP]. Blog: http://spaces.live.com/laflour
team blog: http://devkids.blogspot.com/

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo
 
Hello Nadav,

Generally .net XmlSerializer will help automatically serialize those .net
data types that has direct mapping in XML/XSD standard. For some particular
classes like Form, Font, or IDiretioary based types, they are still not
supported by built-in xml serialization. Here is a blog article which has
explained some of the XML serialization limits:

XML Serialization Frequently Asked Questions
http://weblogs.asp.net/sbehera/archive/2005/12/02/432184.aspx

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi Steven,

I've read link you provided.
They list limitations of the xml serializer but all they say about the
IDictionary interface is this:

A: The XmlSerializer cannot process classes implementing the IDictionary
interface. This was partly due to schedule constraints and partly due to the
fact that a hashtable does not have a counterpart in the XSD type system. The
only solution is to implement a custom hashtable that does not implement the
IDictionary interface.

When I started working with dotnet (1.0/1.1) I thought that IDictionary were
not supported due to schedule constraints.
Now I have to assume that this is a design decision.
As I understand it, the xml serialization saves the data without any
information about the implementation of the classes.
There is nothing to prevent you from serializating a List<int> and then
deserializing it into a int[], is there?
From a purely data oriented point of view a Dictionary is a collection of
pairs: key -> value.
The implementation details should not matter when you serialize it to xml,
so why can't you serialize it as List<KeyValuePair<TKEY,TVAL>>?

The fact that you don't have a counterpart in the XSD type for dictionary
might mean that you don't HAVE to support IDictionary in order to support
everything the XSD allows you to specify, But I don't think XSD knows about
the difference between an int[],List<int> or Collection<int>, does it?

It's very irritating to have to write wrappers for all objects that have
IDictionary properties.

Thanks,
Nadav
 
Thanks for your reply Nadav,

I can understand your concern about writing the additional wrappers for
each diciontary based classes. For this limitation, I surely agree that
there has implementation consideration that make the product team discard
adding the feature in latest framework. I'm sure the product team has been
awared of such requests and most of the update in new release of framework
are comming from community requests. So far I could only say that the dev
team may have their certain restriction or limitation. Anyway, you can
still open new or rate existing feature requests on the product feedback
center to the dev team:

http://connect.microsoft.com/feedback/default.aspx?SiteID=210

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top