NOTE: XMLIgnore is NOT the answer!
OK, so following on from my question on XML Serialization and Inherited Types, I began integrating that code into my application I am working on, stupidly thinking all will go well..
I ran into problems with a couple of classes I have that implement IEnumerable and ICollection<T>
The problem with these is that when the XMLSerializer comes to serialize these, it views them as an external property, and instead of using the property we would like it to (i.e. the one with our AbstractXmlSerializer ) it comes here and falls over (due to the type mismatch), pretty much putting us back to square one. You cannot decorate these methods with the XmlIgnore attribute either, so we cannot stop it that way.
My current solution is to remove the interface implementation (in this current application, its no real big deal, just made the code prettier).
Do I need to swallow my pride on this one and accept it cant be done? I know I have kinda pushed and got more out of the XmlSerializer than what was expected of it 🙂
Edit
I should also add, I am currently working in framework 2.
Update
I have accepted lomaxx’s answer. In my scenario I cannot actually do this, but I do know it will work. Since their have been no other suggestions, I ended up removing the interface implementation from the code.
you can get around this problem by getting hold of the System.RunTime.Serialization dll (it’s a .net 3.x assembly) and referencing it from your .net 2.0 application. This works because the .net 3.0 binaries are compiled to run on the .net 2.0 CLR.
By doing this, you get access to the DataContractSerliazer which I’ve used to get around a similar problem where I wanted to pass in a ICollection as a parameter to a webservice and the xmlserializer didn’t know how to deal with it properly.
If you’re cool with using the .net 3.x dll in your 2.x application you should be able to use the DataContractSerializer to solve this problem