ConfigurationSettings vs Properties.Settings

I have a Winform app that has 16 SQL Connections currently stored in the DAL Projects Settings.settings.

I am trying to write a "Manager" class to simplify this(like here). However, most of the examples I find on the web seem to use ConfigurationSettings.AppSettings["something"]. While, I WAS using Properties.Settings.Default.something.

C开发者_StackOverflow社区an someone, please, explain which is considered CORRECT and why for a Desktop applications?

I think the correct way is to use the app.config file and store them in the connectionStrings section?

Then you can access them like:

 ConfigurationManager.ConnectionStrings["something"].ConnectionString

You could write a wrapper around that easily if that is too "ugly".

public class ConnectionManager
{
    public string Something
    {
        get
        {
             // TODO: check to make sure the configuration exists and throw an exception perhaps
             return ConfigurationManager.ConnectionStrings["something"].ConnectionString;
        }
    }
}

Oops...as pointed out I meant to do ConfigurationManager and not ConfigurationSettings.

I've never been a big fan of putting sql connection strings into configuration files for software. Users have a habit of goofing them up out of curiosity or stupidity (or some combination of the two). I like to put all of my connection strings (development, model, production, whatever) into the Properties of my data access library, and include within it a ConfigurationSettings class that I use to access them based on some property that is set by the consuming application:

public class ConfigurationSettings
{

    public static string MyConnectionString
    {
    get
            if(ConfigurationSettings.TestMode)
                return Properties.Settings.Default.MyConnectionStringTest;
            else
                return Properties.Settings.Default.MyConnectionStringProd;
    }
    }

    // I typically only have test and not-test. This could
    // easily be some other combination of values to satisfy
    // multiple environments.
    public static bool TestMode { get; private set;}
}

This allows me to call the static properties of this class through a common name and have all connection strings available depending on some criteria. This gets your specific datasets, entities, whatever data model you're using from being in the business of worrying about connection strings and the settings can be compiled into the .dll (and no longer need to worry about them). This method can also be modified to pull settings from an app.config (which I do for ASP.Net sites) in a similar method.

UPDATE: There really is no "correct" way as you imply. The app.config was designed to hold configuration settings that are modifiable without rebuilding the application. Property Settings were designed to hold settings that are not modifiable. So both are perfectly valid. Probably the most "correct" way is a way that makes sense both for your application and for your development team.

We prefer to use Properties.Settings (aka. settings.settings) because it's strongly typed. Don't try to do fancy tricks that have different environments (dev/prod) in the same config file. It is much easier to have a separate config file per environment, and to rename the configs when you deploy them. i.e.

app.config 
app.stage.config
app.test.config
app.prod.config

We use PowerShell scripts (batch files on steroids) to do our deployments. I'll simplify what we do as a traditional batch file - (pseudo code/untested sample):

@echo off
:: %1 is the environment name (first parameter)
setlocal
set source=c:\tfs\project\bin\release\
set target=\\server\share\path\

xcopy /s/e %source% %target%

:: Using a copy command to rename/overwrite the env specific version
if exists %target%\app.%1.config copy /y %target%\app.%1.config %target%\app.config

Properties.Settings.Default are generally used to save application internal state like the color of the background, to remember user settings.

ConfigurationSettings is actually the "Manager" class you were talking about and can access other custom sets of settings from the app.config file, including connection strings.