Workaround for XmlSerializer T[] and List bug

Avatar

Andrew

The XmlSerializer in NetCF 2.0 has a bug where if a single serialization requires reflecting into types that use a mixture of Collection<T>-like types for the same T the XmlSerializer will throw an exception.  Here an example where CF 2.0 would crash:

This type would fail to serialize under NetCF 2.0 because T = string would appear in two kinds of collections. This next example would also fail if you were serializing TypeA, because it contains a TypeB instance which has the another kind of T collection.

If you can change the public API to use all T[] or List<T> and avoid the mixture, you’ve worked around the problem. So this would be the simplest workaround:

If you can’t change the public API to maintain compatibility for your customers, here’s another workaround that will eliminate the mixture for the XmlSerializer but keep the mixture for your customers.

This will make the XmlSerializer work, and the API to the customer appear to be the same, except for a public member that they should never use directly that is only there (and public) because the XmlSerializer requires it.  EditorBrowsableAttribute and ObsoleteAttribute are there to help the customer to not run into that member and use it when you didn’t intend them to. 

This bug is fixed in .NET Compact Framework 3.5.

Avatar
Andrew Arnott

Principal Software Engineer, Visual Studio Platform

Follow Andrew   

0 comments

    Leave a comment