Как уже упоминалось в последующем комментарии к исходному вопросу, .NET генерирует сборки при создании XmlSerializer и кэширует сгенерированную сборку, если она создана с использованием одного из этих двух конструкторов:
XmlSerializer(Type)
XmlSerializer(Type, String)
Сборки, созданные с использованием других конструкторов, не кэшируются, поэтому .NET должен каждый раз генерировать новые сборки.
Почему? Этот ответ, вероятно, не очень удовлетворителен, но, взглянув на это в Reflector, вы можете видеть, что ключ, используемый для хранения и доступа к сгенерированным XmlSerializer
сборкам (TempAssemblyCacheKey
), представляет собой простой составной ключ, созданный из сериализуемого типа и (опционально) его пространство имен.
Таким образом, нет механизма, позволяющего определить, имеет ли кэшированный XmlSerializer
для SomeType
специальный XmlRootAttribute
или значение по умолчанию.
Трудно придумать техническую причину, по которой ключ не может вместить больше элементов, так что это, вероятно, просто функция, которую никто не успел реализовать (тем более что это повлекло бы за собой изменение в противном случае стабильных классов).
Возможно, вы видели это, но в противном случае в документации XmlSerializer
класса обсуждается обходной путь:
Если вы используете какой-либо другой
конструкторы, несколько версий
одна и та же сборка генерируется и никогда
выгружен, что приводит к памяти
утечка и низкая производительность. Самый легкий
Решение заключается в использовании одного из
ранее упоминалось два конструктора.
В противном случае вы должны кэшировать
сборки в Hashtable,
, как показано на
следующий пример.
(пример здесь опущен)