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)

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.

commented: Valuable Registry Info +3

Same here, i use My.Settings.

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.

commented: This makes me happy as I don't have to change my personal preference hehehe +3

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.

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.

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

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

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.

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.

Note: Serializeable objects must be public.

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.

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.

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.

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...

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.