Preferred Method For Saving Program Settings

[J.C. SolvoTerra]

I have used several methods to save a program's settings in the past.

• System Registry
• INI files (Encrypted\Plain)
• XML file as a resource or external file
• XML app.config

etc.

I'm wondering either:

1. What's your preferred method for saving your program's settings?
2. Is there a preffered industry standard?
3. Does .Net provide a namespace for reading writing a programs settings?
4. As VS creates settings in XML in the app.config file should I sipmly take this as preferred.

In short... what's YOUR prefered method OR what's the PROPER method =0)

[Reverend Jim]

I find it easiest to use My.Settings. I don't know if there is an industry standard but I prefer to avoid the registry whenever possible.

[oussama_1]

Same here, i use My.Settings.

[deceptikon]

What's your preferred method for saving your program's settings?

It depends on the settings and the complexity of the program in my case. For simpler things, I prefer app.config. For more complex things I prefer my own XML file using serialization. Sometimes I'll go with storing settings in a database. The registry is not recommended.

Is there a preffered industry standard?

Not a single one. :)

Does .Net provide a namespace for reading writing a programs settings?

Yes. The API that facilitates app.config is exposed for you to use. However, unless you're using it in conjunction with app.config, things get hairy. I vastly prefer managing custom XML or INI separately.

As VS creates settings in XML in the app.config file should I sipmly take this as preferred.

That should be your default preference when all else is equal.

[J.C. SolvoTerra]

I too am a stickler for serializing XML or even a basic INI. Have never used the My.Settings object, though now I will fully research it as it's probably the way foward with "For simpler things, I prefer app.config."

if three reputable engineers are stating the use of App.Config, I'd better get on it.

I'll leave this thread open for a few days, would like to see if there's any oddities that may be of interest.

Thanks guys.

[Santanu Das]

Agreed with deceptikon. I also prefering own XML file with Serialization more than a database. I never try to use App.config file. I always try to keep it in safe position. I like to leave it for VS. Use of Serialization in XML file to store configarations is more convenient than the use of databases.

[J.C. SolvoTerra]

I can see how a database would be very useful for much larger projects that may have shared resources and settings.

[Reverend Jim]

Would anyone care to post a simple example of managing settings with xml serialization?

[Santanu Das]

You can use both as a resource file. Using LINQ you can use them beautifully in your application. But I do not prefer to open any database before full loading of all resources, supporting files used by the application in memory. Even if the application uses any userID, Password to run.

[J.C. SolvoTerra]

Here's a simple set of settings\Data. Much more in-depth structures can be used.

Imports System.IO
Imports System.Xml.Serialization

Public Class Form1

    <Serializable()> _
    Public Class Settings

        Private _Name As String
        Public Property Name As String
            Get
                Return _Name
            End Get
            Set(value As String)
                _Name = value
            End Set
        End Property

        Private _Age As String
        Public Property Age As String
            Get
                Return _Age
            End Get
            Set(value As String)
                _Age = value
            End Set
        End Property

        Private _Title As String
        Public Property Title As String
            Get
                Return _Title
            End Get
            Set(value As String)
                _Title = value
            End Set
        End Property

        Private _ContactNumber As String
        Public Property ContactNumber As String
            Get
                Return _ContactNumber
            End Get
            Set(value As String)
                _ContactNumber = value
            End Set
        End Property
    End Class

    Public MySettings As Settings

    Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load

        MySettings = New Settings
        MySettings.Name = "Jay Clark"
        MySettings.Age = "33"
        MySettings.Title = "Mr."
        MySettings.ContactNumber = "Ha... as if"

    End Sub

    'Serialize The Settings Class to XML
    Private Sub Button1_Click(sender As Object, e As EventArgs) _
        Handles Button1.Click

        Dim sWriter As New _
            StreamWriter("C:\Users\Jay\Documents\test.xml")

        Dim XMLS As New XmlSerializer(MySettings.GetType)

        XMLS.Serialize(sWriter, MySettings)

        sWriter.Close()

    End Sub

    'Read XML Into Settings Object
    Private Sub Button2_Click(sender As Object, e As EventArgs) _
        Handles Button2.Click

        Dim sReader As New _
            StreamReader("C:\Users\Jay\Documents\test.xml")

        MySettings = New Settings

        Dim XMLS As Xml.Serialization.XmlSerializer = New _
        XmlSerializer(MySettings.GetType)

        MySettings = XMLS.Deserialize(sReader)

        sReader.Close()

        Console.WriteLine(MySettings.Name)


    End Sub
end sub

Which gives you an xml settings\Data file like this

<?xml version="1.0" encoding="utf-8"?>
<Settings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Name>Jay Clark</Name>
  <Age>33</Age>
  <Title>Mr.</Title>
  <ContactNumber>Ha... as if</ContactNumber>
</Settings>

I'd then usually run this over with a little AES just for good measure.

[J.C. SolvoTerra]

Note: Serializeable objects must be public.

[Reverend Jim]

Perhaps it's just me but it seems like a lot of trouble to go through to avoid using the builtin My.Settings. And you have to modify the code every time you want to add a new setting.

[J.C. SolvoTerra]

I totally agree reverend jim. For much larger data sets i do prefer it. I tend to write a mutable class to allow the easy ammendments of new variables. But it was for smaller collectios of data like this i wanted to learn alternatives. Rest assured the My.Settings is undoubtedly the approach i need to adopt.

[deceptikon]

Perhaps it's just me but it seems like a lot of trouble to go through to avoid using the builtin My.Settings.

After a fashion. Certainly naive use of My.Settings is simpler than managing a configuration class, serialization, and encryption in a more manual manner. That's precisely why for simple cases I prefer the former.

However, when you run into limitations of My.Settings, working around them without switching to a different solution entirely becomes non-trivial very quickly.

[J.C. SolvoTerra]

Can anyone provide links/source to good working examples design and run time. Creating, editing and general management of the settings namespace.

I'm currently pottering about with MSDN...