Introduction
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
Constants
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’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>
</div>
```vbnet
'------------------------------------------------------------------------------
' <auto-generated>
' 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.
' </auto-generated>
'------------------------------------------------------------------------------
Option Strict On
Option Explicit On
<Global.System.Runtime.CompilerServices.CompilerGeneratedAttribute(), _
Global.System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.VisualStudio.Editors.SettingsDesigner.SettingsSingleFileGenerator", "10.0.0.0")> _
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
Get
Return defaultInstance
End Get
End Property
<Global.System.Configuration.UserScopedSettingAttribute(), _
Global.System.Diagnostics.DebuggerNonUserCodeAttribute(), _
Global.System.Configuration.DefaultSettingValueAttribute("testvalue")> _
Public Property test() As String
Get
Return CType(Me("test"), String)
End Get
Set(ByVal value As String)
Me("test") = value
End Set
End Property
End Class
Pros
Scope, you can change them at runtime, typesafe, a GUI.
Cons
A big mess of generated code, a black box which sometimes does things you don’t know about, A GUI.
XML
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.
Pros
Flexible, can be made to change at runtime, human readable.
Cons
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.
Pros
Central settings so easy backup, runtime update-able.
Cons
Slow, not available when no connection to server.
ResourceManager
This is used for localization, you can read all about it on this codeproject article. I would use it for nothing else then localization.
Pros
Localizable.
Cons
Localizable.
COnclusion
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.
Chris is awesome.
