4

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

Community
  • 1
  • 1
kmote
  • 14,865
  • 10
  • 62
  • 84
  • Does "standardize" in this case mean that your classes would directly acquire the connection string/other settings by using `ApplicationSettings`? – Yacoub Massad Nov 10 '15 at 20:30
  • @YacoubMassad: yes, I would like to acquire all settings, including connection strings using the syntax `Properties.Settings.Default.x` – kmote Nov 10 '15 at 20:37
  • Are you enitiy framework? or straight ado.net? – Black Frog Nov 10 '15 at 20:42
  • @BlackFrog: no framework. Just straight C# – kmote Nov 10 '15 at 20:48
  • 1
    @IanP: I saw that post (and even linked to it). But it is almost 7 yrs old, and the selected answer points to articles that are nearly _10_ yrs old. – kmote Nov 10 '15 at 20:49

5 Answers5

3

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.

D Stanley
  • 139,271
  • 11
  • 154
  • 219
2

I suggest that you keep your classes settings-source agnostic.

For example if you have a DatabaseContext that requires a connection string, then inject that primitive dependency in the constructor. Do not locate the connection string directly via ApplicationSettings.

Locating primitive dependencies (e.g. settings) from your classes is exactly the same as using the Service Locator anti-pattern.

The only location in your application that should acquire settings (e.g. connection strings) is the Composition Root. So you can obtain settings from ApplicationSettings here and inject them into your classes.

This allows you to change your mind later if you want to use a different way for storing/retrieving settings.

Yacoub Massad
  • 26,006
  • 2
  • 31
  • 56
  • 1
    Absolutely, but it's the composition root (or more specifically, the Data Access Layer) that I am creating at the moment, so that doesn't really answer my question. (I've got to acquire the settings data _somewhere_ in the code). The composition root isolates the question but it doesn't eliminate it. – kmote Nov 10 '15 at 20:55
  • @kmote, Does your Data Access Layer live inside its own application/process? – Yacoub Massad Nov 10 '15 at 21:08
  • At the moment, yes. (It's only a single class with a few simple methods). But I'm afraid I don't see how that's relevant to my question. – kmote Nov 10 '15 at 21:30
  • Based on your answer that you gave when I asked about the meaning of "standardizing", I though (mistakenly, as it seems to me now), that you are asking whether you should use `ApplicationSettings` from your classes. My answer is giving you are reason why not to do that. – Yacoub Massad Nov 10 '15 at 21:42
  • Oh, yes, I see the confusion now. I misunderstood your original question. Thank you for the clarification. – kmote Nov 10 '15 at 22:12
2

As you must have read on the pages that you linked to, the main benefit of using <connectionStrings> is that it provides mechanisms for encrypting the strings in order not to keep passwords in clear text. If you use Windows authentication to connect to the database then I guess you don't need it and really doesn't matter where you keep your connection strings. It's just a standard way of doing this.

I believe, however, that you are mistaken saying that the 'old syntax' is deprecated. For example, <appSettings> is still documented, it just changed the address. It would bring havoc if it was. It's not my area, but I think what you refer to as the 'new syntax' is the way of accessing settings in a desktop application, you don't have it in server-side applications.

kamilk
  • 3,043
  • 1
  • 23
  • 36
  • Thank you for the clarification on the documentation link. (I have notified the maintainers of [this page](https://msdn.microsoft.com/en-us/library/1xtk877y(v=vs.110).aspx#Anchor_2), which links to the old address.) – kmote Nov 10 '15 at 22:21
1

I believe the ApplicationSettings element is just used for organization. If you notice in Entity Framework or most other database connections, they store them in the config under the ConnectionStrings element. The only thing I would worry about is storing any sort of sensitive data such as connection user and password. A common way to get around that is to allow the Windows Authentication to handle the connection.

PantAaroN
  • 63
  • 9
0

A standard is what you make. For example in my current work environment the only information that changes in a particular application is the server name. We have dev/test/prod servers. Therefore we only store the SQL Server name in the configuration file. The database name doesn't change. We just read the database server from the configuration file and build the string in the application.

Black Frog
  • 11,168
  • 1
  • 31
  • 64