Question

I’m just about to start writing a new application and I wanted to sort out how I store settings. I almost considered writing my own settings system but then decided I should really fully test the build application settings that .NET provides. So I had a read about it and created some testing code. It was going fine, the main thing I wanted was a way to reset values which it can do easily but I wanted to do this without automatically saving the reset to the settings file.

So I create the following code that loops over each property of the settings class and uses the default
value to update the current value.

        foreach (SettingsProperty sp in Settings.Default.Properties)
        {
            PropertyInfo propertyInfo = Settings.Default.GetType().GetProperty(sp.Name);

            if (propertyInfo.CanWrite)
            {
                // Either convert from a string or de-serialize from XML
                object value;
                switch (sp.SerializeAs)
                {
                    case SettingsSerializeAs.String:
                        TypeConverter converter = TypeDescriptor.GetConverter(sp.PropertyType);
                        value = converter.ConvertFromInvariantString(sp.DefaultValue.ToString());
                        break;
                    case SettingsSerializeAs.Xml:
                        XmlSerializer serializer = new XmlSerializer(sp.PropertyType);
                        StringReader reader = new StringReader(sp.DefaultValue.ToString());
                        value = serializer.Deserialize(reader);
                        break;
                    default:
                        throw new FormatException(
                            string.Format(
                                Resources.ExceptionResetNoSaveSerializeAsInvalid,
                                sp.SerializeAs));
                }

                propertyInfo.SetValue(Settings.Default, value, null);
            }
        }

I started off without the switch and only the code to convert from a string. My first attempt had used this: converter.ConvertFromString. This worked fine with just plain text and even GUID values but it failed with dates.
(The XML part I added so that serialized content worked as well but that is not the focus of this question)

The original converter.ConvertFromString failed on dates. In my test I was using ’31/08/2012 11:25′. I had been looking at the Settings.Designer.cs file to see where and how it stored default values and noticed this is how it stored the default for the above date:

    [global::System.Configuration.DefaultSettingValueAttribute("08/31/2012 11:25:15")]

I’ve been searching online but I cannot find any reference to explain why entering the dd/mm/yyyy format in the Visual Studio 2010 designer resulted in the use of the mm/dd/yyyy format in the auto generated code.

As you can see in the example above I found that I could use converter.ConvertFromInvariantString and the date error does go away but I would still like to know if there is any documentation to explain the difference. Has anyone else come across this?

Answer 1

Yes and no. The internals uses the invariant culture. While that is a specific culture, it’s obviously not a real culture.

Internally it uses methods like TypeConverter.ConvertToInvariantString and TypeConverter.ConvertFromInvariantString to get values in/out of strings. This is why the mm/dd/yyy in the strings. When you enter a date/time in the UI it knows what the local culture is and accepts it in whatever format is correct for that culture. It then “converts” to invariant when it stores it. It does this because it won’t know what culture will be set when it reads the value. It defaults to invariant because that is a specific and consistent culture.

In terms of DateTime, this results in neither a UTC nor a local Date/Time. This allows you to store either UTC or local date/time values, you’ll need to “convert” to DateTime object with the specific Kind property set to whatever you need it to be. It’s recommended that you store date/time values in UTC…