Обаружил противный баг в методе XmlSerializer.Deserialize.
Суть:
Если сериализован класс со строковыми полями содержащими escapе characters like \r\n\t то сериализуются они нормально, при десериализации вычитываются в поток тоже нормально, но как только мы делаем Deserialize для объекта то в стоковые поля попают с строки с искаженными последовательностями таких символов. Наблюдаются разные искажения но чаще всего исчезает символ \r или он же заменяется на \t.
Была мысль поотлаживать создаваемый слр код десериализатора, а смысл,
потеряю времени день два, может даже найду баг, а чего дальше с этим делать, собственный десериализатор для нескольких десятков классов как-то не вписывается в проект по срокам...
Это критичная часть проекта, и как обойти не представляю, вынимать строки через regexp... бред.
