What is the difference between connectionstrings and appsettings?

Question

In one of the applications I have been referring to, the Connection String is stored in AppSettings! Till now I have been storing the connection in the <connectionstring/> element. But what is the correct way?

So my question is, what are the differences between <connectionstrings> and <appsettings> in the web.config and are there any specific reasons why I should or should not be storing connection strings in appsettings? Are there any rules / guidelines provided to follow? Or is this completely the choice of the developer?

Answer 1

There is a fundamental difference between connectionString and appSettings:

They look for different things. In .NET 2.0 and above:

A connectionString object is an XML node that has specific attributes to set; and semantically it refers to a database connection string.

For instance, a connectionString looks like the following:

<connectionStrings>
    <clear/>
    <add name="LocalSqlServer"
          connectionString="Data Source=(local);Initial Catalog=aspnetdb;Integrated Security=True"
          providerName="System.Data.SqlClient" />
  </connectionStrings>

You'll notice it has a few different attributes:

• name
• connectionString : This has a specific string inside of it, it needs an Initial Catalog, a security mechanism (in this case Integrated Security
• providerName

Whereas appSettings is just a user-defined Key-value pair that allows you to... well... set application settings. It can be anything:

<appSettings>
    <add key="Mom" value="Your"/>
    <add key="UseCache" value="True"/>
    <add key="MapsKey" value="1234567890-AA"/>
    <add key="SMTPServer" value="smtp.peterkellner.net"/>
</appSettings>

In many cases, it would just be odd to put the connectionString in a key-value pair like appSettings (semantically and programmatically). As well as it would make it more difficult to encrypt the connectionString when you need to.

There is more information about this from this blog post.

Answer 2

As far as I know it doesn't make a huge amount of difference, other than it being in the "correct" place - the main advantage of putting connection strings in their own section (you do encrypt your connection strings.. right?) is so you can encrypt that section without encrypting all of the settings you might want to change.

Answer 3

Connection strings are generally kept in the <connectionstring/> element...and is a good guideline since it's named properly.

Sometimes you might use a third party control or usercontrol that looks for the connection string in a key in the <appsettings> element. That should be the only exception to the guideline.

Answer 4

Additionally, in IIS7, connect strings can be maintained through the respective IIS7 Administration.

Answer 5

You can use appSettings section to share custom application configuration settings across projects in .NET.

How to share custom application configuration settings across projects in .NET

Answer 6

Regarding deployment, there's one significant difference between them. When you import web packages to IIS:

• Connection strings will automatically be included in the wizard dialog for further parameterization.
• App settings will not be there by default. If you really want to do that, please follow the steps in "Custom Parameterization - Application settings in the web.config file" section of Configuring Parameters for Web Package Deployment

That means, when it comes to deployment, you'd better put environment parameters(database, cache, AWS key/secret, etc.) in connection strings. It will provide differentiation between dev/staging/prod environment explicitly.