XmlWriter passed to ConfigurationElement.SerializeElement is always null on Configuration.Save

When extending System.Configuration.ConfigurationElement and overriding the DeserializeElement eveything works as expected and can get what I need from it the XmlReader that is always provided and functional.

Unfortunately when I override the SerializeElement the XmlWriter that is provided to it is always null for some reason I am yet to determine why. I have tried overriding other methods and calling the base.SerializeElement first thing in the call. Regardless I have yet to find a way to make sure that the XmlWriter passed to SerializeElement when the Configuration.Save method is called is not null.

Answers


I did some more digging by looking at the source for the System.Configuration.ConfigurationElement to see what it is doing when it calls SerializeElement. Apparently SerializeToXmlElement is the primary caller and it has the following block of code.

if (SerializeElement(null, false) == true) // check if there is anything to write...
{
    if (writer != null)
        writer.WriteStartElement(elementName);
    DataToWrite |= SerializeElement(writer, false);
    if (writer != null)
        writer.WriteEndElement();
}

As you can see it first passes null to see if it needs to serialize anything and if it returns true then it passes the actual writer.

This is undocumented in the MSDN docs. My solution to resolve this is to keep the modified methods overrides with tracking of changes and then add this to the top of my SerializeElement.

if (writer == null)
    return isModified;

So I am not sure why it doesn't used its own IsModified method to know if it needs to serialize or not, as this is a very odd way to do it. However this solution works.


Need Your Help

Is fopen safe to use in public software?

php security fopen

I am creating a web application that I hope to release to the public for downloading and installing on anyone's own web server, however I just was informed that some webhosts disable the use of fop...

Use a different region notation than the system's region notation

ios cocoa-touch uikit

On iOS, an app can use a different language than the system language if the developer passes the NSLocale to the right instances, or else if the proper values are written to NSUserDefault's