Глюки сериализации XML.NET? [закрытый]

Другой огромный глюк: при выводе XML через веб-страницу (ASP.NET) Вы не хотите включать порядок байтов Mark Unicode. Конечно, способами использовать или не использовать BOM является почти то же:

ПЛОХОЙ (включает BOM):

XmlTextWriter wr = new XmlTextWriter(stream, new System.Text.Encoding.UTF8);

ХОРОШИЙ:

XmlTextWriter  wr = new XmlTextWriter(stream, new System.Text.UTF8Encoding(false))

можно явно передать ложь, чтобы указать, что Вы не хотите BOM. Заметьте ясное, заметное отличие между Encoding.UTF8 и UTF8Encoding.

три дополнительных Байта BOM вначале (0xEFBBBF) или (239 187 191).

Ссылка: http://chrislaco.com/blog/troubleshooting-common-problems-with-the-xmlserializer/

Частные переменные/свойства не сериализируются в сериализации XML, но находятся в двоичной сериализации.

я полагаю, что это также получает Вас при представлении членов парламента, не занимающих официального поста через общественные собственности - члены парламента, не занимающие официального поста не становятся сериализированными, таким образом, общедоступные участники все ссылаются на нулевые значения.

Если Ваш XSD использует группы замены, то возможности - Вы, не может (de) сериализировать его автоматически. Необходимо будет записать собственные сериализаторы для обработки этого сценария.

, Например,

<xs:complexType name="MessageType" abstract="true">
    <xs:attributeGroup ref="commonMessageAttributes"/>
</xs:complexType>

<xs:element name="Message" type="MessageType"/>

<xs:element name="Envelope">
    <xs:complexType mixed="false">
        <xs:complexContent mixed="false">
            <xs:element ref="Message" minOccurs="0" maxOccurs="unbounded"/>
        </xs:complexContent>
    </xs:complexType>
</xs:element>

<xs:element name="ExampleMessageA" substitutionGroup="Message">
    <xs:complexType mixed="false">
        <xs:complexContent mixed="false">
                <xs:attribute name="messageCode"/>
        </xs:complexContent>
    </xs:complexType>
</xs:element>

<xs:element name="ExampleMessageB" substitutionGroup="Message">
    <xs:complexType mixed="false">
        <xs:complexContent mixed="false">
                <xs:attribute name="messageCode"/>
        </xs:complexContent>
    </xs:complexType>
</xs:element>

В этом примере, Конверт может содержать сообщения. Однако сериализатор.NET по умолчанию не различает сообщение, ExampleMessageA и ExampleMessageB. Это только сериализирует к и от основного Класса сообщений.

Будьте осторожными типами сериализации без явной сериализации, она может привести к задержкам, в то время как .NET создает их. Я недавно обнаружил это при сериализации RSAParameters.

Я не могу действительно объяснить этого, но я нашел, что это не сериализирует:

[XmlElement("item")]
public myClass[] item
{
    get { return this.privateList.ToArray(); }
}

, но это будет:

[XmlElement("item")]
public List<myClass> item
{
    get { return this.privateList; }
}

И также стоящий замечания, что, если Вы сериализируете к memstream, Вы могли бы хотеть искать на 0 перед использованием его.

Частные переменные/свойства не сериализируются в механизме по умолчанию для сериализации XML, но находятся в двоичной сериализации.

Можно столкнуться с проблемами, сериализирующими объекты цвета шрифта и/или Шрифта.

Вот советы, которые помогли мне:

http://www.codeproject.com/KB/XML/xmlsettings.aspx

http://www.codeproject.com/KB/cs/GenericXmlSerializition.aspx

Еще одна вещь отметить: Вы не можете сериализировать частных участников / членов защищенного класса при использовании сериализации XML "по умолчанию".

, Но можно указать пользовательскую логику сериализации XML реализация IXmlSerializable в классе и сериализировать любые частные поля, в которых Вы нуждаетесь/хотите.

http://msdn.microsoft.com/en-us/library/system.xml.serialization.ixmlserializable.aspx

О, вот хороший: так как код сериализации XML сгенерирован и помещен в отдельный DLL, Вы не получаете значимой ошибки, когда существует ошибка в Вашем коде, который повреждает сериализатор. Просто что-то как "не могущий определить местоположение s3d3fsdf.dll". Хороший.

Не может сериализировать объект, который не имеет construtor без параметров (просто был укушен тот одним).

И по некоторым причинам, от следующих свойств, Значение сериализируется, но не FullName:

    public string FullName { get; set; }
    public double Value { get; set; }

я никогда не возвращался к разработке, почему, я просто изменил Значение на внутренний...

Вы не можете сериализировать свойства только для чтения. У Вас должны быть метод считывания и метод set, даже если Вы никогда не намереваетесь использовать десериализацию для превращения XML в объект.

По той же причине, Вы не можете сериализировать свойства, которые возвращают интерфейсы: deserializer не знал бы что реального класса инстанцировать.

Когда сериализация в XML представляет в виде строки от потока памяти, убедиться использовать MemoryStream#ToArray () вместо MemoryStream#GetBuffer (), или Вы закончите с символами спама, которые не десериализуют правильно (из-за дополнительного выделенного буфера).

http://msdn.microsoft.com/en-us/library/system.io.memorystream.getbuffer (По сравнению с 80) .aspx

Я еще не могу сделать комментарии, таким образом, я прокомментирую сообщение Dr8k и сделаю другое наблюдение. Частные переменные, которые выставляются как общедоступные свойства метода считывания/метода set и действительно добираются, сериализировали/десериализовали как таковой через те свойства. Мы сделали это в моем старом задании al время.

Одна вещь отметить, хотя то, что, если у Вас есть какая-либо логика в тех свойствах, логика выполняется, поэтому иногда, порядок сериализации на самом деле имеет значение. Участники неявно приказаны тем, как им заказывают в коде, но нет никаких гарантий, особенно при наследовании другого объекта. Явно упорядочивание их является болью сзади.

я был записан этим в прошлом.

IEnumerables<T>, которые сгенерированы через возвраты урожая, не являются сериализуемыми. Это вызвано тем, что компилятор генерирует отдельный класс для реализации возврата урожая, и тот класс не отмечен как сериализуемый.

Если сгенерированный блок Вашей Сериализации XML не будет в том же контексте Загрузки как код, пытающийся использовать его, то Вы столкнетесь с потрясающими ошибками как:

System.InvalidOperationException: There was an error generating the XML document.
---System.InvalidCastException: Unable to cast object
of type 'MyNamespace.Settings' to type 'MyNamespace.Settings'. at
Microsoft.Xml.Serialization.GeneratedAssembly.
  XmlSerializationWriterSettings.Write3_Settings(Object o)

причиной этого для меня был плагин, загруженный с помощью контекст LoadFrom , который имеет много недостатков к использованию контекста Загрузки. Довольно мало забавы, разыскивающей, что один.

Если сериализатор обнаруживает член / свойство, имеющее интерфейс в качестве своего типа, он не будет сериализован. Например, следующее не будет сериализовано в XML:

public class ValuePair
{
    public ICompareable Value1 { get; set; }
    public ICompareable Value2 { get; set; }
}

Хотя это будет сериализовано:

public class ValuePair
{
    public object Value1 { get; set; }
    public object Value2 { get; set; }
}