none
Complex objects in Application Settings RRS feed

  • Question

  • Hi,

    Although MSDN states the following:

    When LocalFileSettingsProvider must save settings to disk, it performs the following actions:
    1. Uses reflection to examine all of the properties defined on your ApplicationSettingsBase derived class, finding those that are applied with either ApplicationScopedSettingAttribute or UserScopedSettingAttribute.
    2. Serializes the property to disk. It first attempts to call the ConvertToString or ConvertFromString on the type's associated TypeConverter. If this does not succeed, it uses XML serialization instead.
    3. Determines which settings go in which files, based on the setting's attribute.

    - my property of complex type does not get serialzed until I implement IXmlSerializable in this type.

    Why? I mean why it doesn't attempt to just call the XmlSerializer?! why does it need IXmlSerializable to be implemented?

    • Edited by Comanche Monday, February 18, 2013 7:00 AM
    Monday, February 18, 2013 6:59 AM

All replies

  • Quoted form MSDN:

    There are two reasons to implement this interface. The first is to control how your object is serialized or deserialized by the XmlSerializer. For example, you can chunk data into bytes instead of buffering large data sets, and also avoid the inflation that occurs when the data is encoded using Base64 encoding. To control the serialization, implement the ReadXml and WriteXml methods to control the XmlReader and XmlWriter classes used to read and write the XML. 

    So there should be some data that can't be (Properly) serialized, you need to create a custom serialization method to do this.

    Sorry for any misunderstood.


    Think again!

    Wednesday, February 20, 2013 6:56 AM
  • Hi Edward,

    Thanks for the answer. I know this.

    Let's take a look once more at the phrase "If this does not succeed, it uses XML serialization instead". Term "XML serialization" doesn't assume mandatory implementation of IXmlSerializable interface! Instances of many types are successfully serialized "as is", i.e. without implementing this interface. That's why I wonder why I had to implement it to make my "complex" property serialize to XML.

    Wednesday, February 20, 2013 9:25 AM
  • Hi Comanche,

    Thank you for posting on MSDN Forum.

    There is no such document mentioned that why it call convertFrom/ToString method in high priority.

    VS provide an UI to edit settings. We always only input a string: a number string, a text string and so on. We do not supposed to input an XML string. The big difference between TypeConvertor and XML serialization is: The XML serializtion is dedicated on serialize it locally and deserialize it remotely, and it can be deserialized remotely. But the typeconvertor can only convert a string back with the same convertor.

    Here is a related thread: http://social.msdn.microsoft.com/Forums/en-US/asmxandxml/thread/ac2e67c9-9548-47f9-8aee-1be9b1ab8b03/

    I hope this will be helpful.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, February 21, 2013 7:06 PM
    Moderator
  • There is no such document mentioned that why it call convertFrom/ToString method in high priority.

    I don't understand what you are talking about. I don't care of the string conversion stuff, my question was about item #2: "If this [string conversion] does not succeed, it uses XML serialization instead".

    VS provide an UI to edit settings.

    - strange to hear such things from Moderator! I'm talking about the way LocalFileSettingsProvider works, about how it serializes settings, and you are talking about how these settings are presented in VS UI... who cares about how they are presented?! how does the UI presentation relate to their serialization?

    We always only input a string: a number string, a text string and so on. We do not supposed to input an XML string. The big difference between TypeConvertor and XML serialization is: The XML serializtion is dedicated on serialize it locally and deserialize it remotely, and it can be deserialized remotely. But the typeconvertor can only convert a string back with the same convertor.

    - excuse me, but I can't even comment this :)))

    PS: I regret that I placed my question here and not directly in the MSDN article (in the "Community Content" section). Maybe I'll do it later.

    [UPDATE] The "Community Additions" section of this MSDN article already has a note titled "SettingsSerializeAs.Xml" (added on 6/22/2010) and stating that IXmlSerializable needs to be implemented. It doesn't explain why, and doesn't of course explain why the article itself does not contain this statement - the note was added by a developer, not by somebody from Microsoft. However, I'm certainly not the first developer who faced this issue.

    • Edited by Comanche Friday, February 22, 2013 4:21 AM
    Friday, February 22, 2013 4:04 AM
  • Hi Comanche,

    I am sorry for making you feel bad.

    >> "If this does not succeed, it uses XML serialization instead".  

    I assumed you try to figure out why it calls convertFrom/ToString method first, rather than XML serializtion. It seems I totally misunderstood you.

    So to make I understand you right this time, do you mean why IXmlSerializable need to be implemented, because we can use "XML serializtion" without implementing this interface?

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, February 25, 2013 8:49 AM
    Moderator