XmlSerializer wierdness

Using XmlSerializer for transport purposes is in general a bad idea. "Ahead of the curve" teams in the industry who believe in using every new thing that comes out usually get caught in these landmines :).

There are a few reasons for this

1. You need to expose every field that you want serialized as a public property/field. What a joy to that your object model does not hide anything ;)
   
2. XmlSerializer does not work for Dictionaries (who would have a dictionary in their api?)
3. XmlSerializer does not work for List of lists and some such (rare, but u will sometimes run into this landmine if you try to solve 2 creatively).
4. You can leak a few dlls (and due to way windows virtual memory works, you will lose atleast 64k of virtual space for every dll) on every serialization attempt if you are not careful (blogged about his before)
5. Many useful framework classes are not xml serializable (e.g. Regex)

Now that we are fairly convinced that it is a bad idea to use xml serializer for transport, we will decide that it is the right choice for configuration files... more about this in future blogs :)

BTW, the DataContractSerializer with dotnet 3.0 solves all these problems and it is an infinitely better beast.