Introduction

In classic .NET applications, app.config and web.config are the standard places for environment-specific settings. The important engineering question is not only how to read a value, but how to do it consistently, validate it early, and keep configuration access from spreading as raw magic strings throughout the codebase.

Know Which Section to Use

The two most common configuration sections are appSettings and connectionStrings. appSettings is for simple key-value strings. connectionStrings is for database or service connection strings.

A small configuration file might look like this:

1<?xml version="1.0" encoding="utf-8" ?>
2<configuration>
3  <appSettings>
4    <add key="Environment" value="Production" />
5    <add key="PageSize" value="50" />
6  </appSettings>
7  <connectionStrings>
8    <add name="MainDb"
9         connectionString="Server=.;Database=SalesDb;Trusted_Connection=True;" />
10  </connectionStrings>
11</configuration>

Use appSettings only for small string values. If the data has real structure, a custom section or a newer options-based configuration model is usually better.

Read appSettings with ConfigurationManager

The classic API is ConfigurationManager.AppSettings. It returns strings, so parsing and validation are your responsibility.

1using System;
2using System.Configuration;
3
4class Program
5{
6    static void Main()
7    {
8        string environment = ConfigurationManager.AppSettings["Environment"];
9        string pageSizeRaw = ConfigurationManager.AppSettings["PageSize"];
10
11        if (string.IsNullOrWhiteSpace(environment))
12        {
13            throw new InvalidOperationException("Missing Environment setting.");
14        }
15
16        if (!int.TryParse(pageSizeRaw, out int pageSize))
17        {
18            throw new InvalidOperationException("PageSize must be an integer.");
19        }
20
21        Console.WriteLine($"Environment: {environment}");
22        Console.WriteLine($"Page size: {pageSize}");
23    }
24}

Failing fast is important. Silent defaults often turn a simple configuration mistake into a confusing runtime bug later.

Read Connection Strings from the Dedicated Section

Connection strings belong in the connectionStrings section, not mixed into appSettings.

1using System;
2using System.Configuration;
3
4class DatabaseSettings
5{
6    public static string GetMainConnectionString()
7    {
8        var entry = ConfigurationManager.ConnectionStrings["MainDb"];
9        if (entry == null || string.IsNullOrWhiteSpace(entry.ConnectionString))
10        {
11            throw new InvalidOperationException("Connection string MainDb is missing.");
12        }
13
14        return entry.ConnectionString;
15    }
16}

That makes the contract explicit and aligns with the conventions used by .NET tools and older frameworks.

Centralize Configuration Access

A useful improvement is to wrap configuration access in one typed class so the rest of the application stops depending on string literals.

1using System;
2using System.Configuration;
3
4public sealed class AppSettingsReader
5{
6    public string Environment => Require("Environment");
7    public int PageSize => int.Parse(Require("PageSize"));
8    public string MainDb => RequireConnectionString("MainDb");
9
10    private static string Require(string key)
11    {
12        string value = ConfigurationManager.AppSettings[key];
13        if (string.IsNullOrWhiteSpace(value))
14        {
15            throw new InvalidOperationException($"Missing app setting: {key}");
16        }
17        return value;
18    }
19
20    private static string RequireConnectionString(string name)
21    {
22        string value = ConfigurationManager.ConnectionStrings[name]?.ConnectionString;
23        if (string.IsNullOrWhiteSpace(value))
24        {
25            throw new InvalidOperationException($"Missing connection string: {name}");
26        }
27        return value;
28    }
29}

This pattern makes refactoring easier and reduces duplicated parsing code.

web.config Uses the Same Core Model

In older ASP.NET applications, web.config is read through the same ConfigurationManager API. The difference is operational rather than conceptual: web.config changes can recycle the application, and different environments often supply different deployed config files.

If you are maintaining legacy web apps, prefer a small typed wrapper around ConfigurationManager rather than reading XML directly. The framework already knows how to resolve configuration sections correctly.

Common Pitfalls

• Storing structured or sensitive connection information in appSettings instead of the correct section makes configuration harder to manage.
• Reading values without validating them turns missing or malformed settings into downstream runtime failures.
• Repeating raw configuration keys throughout the codebase makes renaming and auditing difficult.
• Mixing older ConfigurationManager usage with newer configuration styles without a clear boundary creates confusion.
• Treating optional and required settings the same way hides which values the app truly depends on.

Summary

• Use ConfigurationManager.AppSettings for simple string settings.
• Use ConfigurationManager.ConnectionStrings for connection string values.
• Parse and validate configuration at the boundary, not deep inside business logic.
• Centralize access behind a typed wrapper instead of scattering magic strings.
• Keep app.config and web.config simple, explicit, and environment-specific.