ASP.NET

appSettings vs connectionStrings in web.config

ASP.NET · By the Postback Notes editorial team · Published 2026-09-26

Both sections store key-value settings outside the code, and both can be changed without recompiling. connectionStrings is the dedicated place for database connections, with a provider name and a typed API; appSettings is for everything else.

<configuration>
  <connectionStrings>
    <add name="Db" providerName="System.Data.SqlClient"
         connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=Shop;Integrated Security=True" />
  </connectionStrings>
  <appSettings>
    <add key="PageSize" value="20" />
    <add key="SupportEmail" value="support@example.org" />
  </appSettings>
</configuration>

Reading them

using System.Configuration; // reference System.Configuration.dll

ConnectionStringSettings db = ConfigurationManager.ConnectionStrings["Db"];
string cs = db.ConnectionString;
string provider = db.ProviderName;

string supportEmail = ConfigurationManager.AppSettings["SupportEmail"];   // null if missing
int pageSize = int.TryParse(ConfigurationManager.AppSettings["PageSize"], out int n) ? n : 20;

Values are strings; convert and validate them. Reading a missing connection string returns null, so ConfigurationManager.ConnectionStrings["Db"].ConnectionString throws a NullReferenceException if the name is misspelled.

In markup, expressions read them too: ConnectionString="<%$ ConnectionStrings:Db %>" on a SqlDataSource, Text="<%$ AppSettings:SupportEmail %>" on a label.

Differences that matter

Different values per environment

Web Config Transforms change values at publish time, for example in Web.Release.config:

<connectionStrings>
  <add name="Db" connectionString="Server=sql01;Database=Shop;Integrated Security=True"
       xdt:Transform="SetAttributes" xdt:Locator="Match(name)" />
</connectionStrings>

Protecting secrets

• Prefer integrated security (the application pool identity) so no password is stored.
• Otherwise encrypt the section on the server: aspnet_regiis -pef connectionStrings C:\inetpub\shop. ASP.NET decrypts it transparently at run time.
• Keep production secrets out of source control by using appSettings file="…" or configSource with a file that is not committed.

Step-by-step guides: get a connection string and connect to SQL Server and read appSettings values.

Common mistakes

• Reading a connection string through AppSettings, or the reverse: each section has its own collection, so the key comes back null.
• Duplicate keys: in appSettings, the last entry wins silently; in connectionStrings, a duplicate name causes a configuration error unless you <remove> or <clear /> inherited entries first.
• Expecting a change in web.config to be invisible: saving the file restarts the application.

ASP.NET Core equivalent

ASP.NET Core replaces web.config sections with appsettings.json, environment variables and other configuration providers. Connection strings live under a "ConnectionStrings" object and are read with configuration.GetConnectionString("Db"); other settings are usually bound to typed options classes. Secrets belong in the Secret Manager during development and in environment variables or a vault in production.

Official documentation

• Microsoft Learn: Connection strings and configuration files
• Microsoft Learn: ConfigurationManager.AppSettings
• Microsoft Learn: Encrypting configuration information using protected configuration