There are several ways you can keep your settings in your application. I can think of several and all have pros and cons. I will try to list the ones I use and why I would use them and why not.

  • Constants
  • Settings
  • XML
  • Table on a database server
  • Resourcemanager


This is simple you make a class or module and you add some constants to it.

Public Class Constants
  Public Const Constant1 As String = "Constant1"
  Public Const Constant1 As String = "Constant1"
End Class```
<span class="MT_green">Pros</span>

This is very simple, typesafe, very fast and easily refactorable. 

<span class="MT_red">Cons</span>

Requires quite a bit of code in VB.Net. And you can&#8217;t change at runtime.

## Settings

You can add a settings file via new item in any visual studio project you want. The files also have a .settings extension. Every setting ha a name, type, scope and value. The settings are actually a bit of XML with some T4-generated code attached to it.

<div class="image_block">
  <a href="/wp-content/uploads/users/chrissie1/settings/settings.png?mtime=1299486179"><img alt="" src="/wp-content/uploads/users/chrissie1/settings/settings.png?mtime=1299486179" width="794" height="181" /></a>

' &lt;auto-generated&gt;
'     This code was generated by a tool.
'     Runtime Version:4.0.30319.1
'     Changes to this file may cause incorrect behavior and will be lost if
'     the code is regenerated.
' &lt;/auto-generated&gt;

Option Strict On
Option Explicit On

&lt;Global.System.Runtime.CompilerServices.CompilerGeneratedAttribute(),  _
 Global.System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.VisualStudio.Editors.SettingsDesigner.SettingsSingleFileGenerator", "")&gt;  _
Partial Friend NotInheritable Class Settings1
    Inherits Global.System.Configuration.ApplicationSettingsBase
    Private Shared defaultInstance As Settings1 = CType(Global.System.Configuration.ApplicationSettingsBase.Synchronized(New Settings1()),Settings1)
    Public Shared ReadOnly Property [Default]() As Settings1
            Return defaultInstance
        End Get
    End Property

	&lt;Global.System.Configuration.UserScopedSettingAttribute(), _
	 Global.System.Diagnostics.DebuggerNonUserCodeAttribute(), _
	 Global.System.Configuration.DefaultSettingValueAttribute("testvalue")&gt; _
	Public Property test() As String
			Return CType(Me("test"), String)
		End Get
		Set(ByVal value As String)
			Me("test") = value
		End Set
	End Property
End Class


Scope, you can change them at runtime, typesafe, a GUI.


A big mess of generated code, a black box which sometimes does things you don’t know about, A GUI.


You can write your own XML and your own code to read it and write to it. Mostly for simple things. Whenever it gets more complicated you will notice that the settings file might already be doing what you have just written.


Flexible, can be made to change at runtime, human readable.


Needs some extra programming.

Table on a database server

You can save your settings in a table on a database server, reading and writing code needs to be written. Updating at runtime is possible. But what happens if the server is no longer available? Meaning that you can only save settings there that you need when connected to the server. Connecting to a server is also slow, by far the slowest of all options.


Central settings so easy backup, runtime update-able.


Slow, not available when no connection to server.


This is used for localization, you can read all about it on this codeproject article. I would use it for nothing else then localization.






Use whatever fits your needs. You would typicaly need more settings files that change at runtime in a webapplication then in a winforms application. Be very carefull with settings that can be changed by users, they have no clue but will change it anyway.