Anything wrong with putting connection strings in applicationSettings? [duplicate]

Question

.NET has supported a number of ways to store configuration settings for quite some time, which has led to a good deal of confusion. It doesn't help that the top three hits for a search for "Settings in C#" over on MSDN are ten years old (and many of the related questions [2] on this venerable site are also 6-7 years old). It is really hard to determine which of the early recommendations have since been deprecated.

In my project I have chosen to use ApplicationSettings (as opposed to AppSettings) because:

1. That appears to be the current recommended approach on MSDN (and here).
2. The AppSettings element appears to be deprecated as of .NET 4+* (topic is "no longer available"; but see "Other Versions" on that page.) _{[*Although, confusingly, the AppSettings Property is still supported]}
3. I prefer to edit the settings in a designer tool, rather than an xml editor.
4. I prefer strongly typed settings.

However, now I need to decide where to put my connection strings. The most current documentation on MSDN (and here on SO, as well as CP) still appears to recommend using the <connectionStrings> section of the app.config. But accessing this from the code requires the use of the old syntax, which I now consider obsolete along with appSettings. In other words, it makes no sense to read one part of the app.config file with the old syntax:

ConfigurationManager.ConnectionStrings["MydDBConnName"];

and another part of the same file with the new syntax:

Properties.Settings.Default.myOtherSetting;

Plus, it prevents me from being able to edit the strings in the designer.

So bottom line: is there any reason not to standardize all my configuration settings (including the connection strings) in the ApplicationSettings element?

Answer 1

The ConnectionStrings section allows you to not only define the connection string in the config, but also lets you choose the provider, so you code can (theoretically) use any subclass of DbConnection, DbCommand, etc.

In reality, however, supporting that kind of flexibility means you have to use SQL statements that are provider-agnostic (meaning you can't do things like date math that do not have a standard SQL syntax), and require more "plumbing" code to create the right types of objects. You can see some examples here.

If you only support one database provider (SQL Server, Oracle, ODBC, OleDB) then there's no real benefit to using ConnectionStrings over a string application setting.