Introduction

App.config is the XML configuration file traditionally used by .NET Framework desktop, console, and service applications. It lets you keep settings outside compiled code so values such as connection strings, API endpoints, and feature flags can change without editing source. The key idea is simple: code reads configuration, but configuration itself lives in a deployable file.

What App.config Actually Does

An App.config file is included in the project and transformed into an output file when you build. For a console app, the built output is typically named something like MyApp.exe.config.

That output file travels with the executable and contains structured XML sections. Common sections include:

• 'appSettings for key-value pairs'
• 'connectionStrings for database connections'
• runtime sections for assembly binding or other framework behavior

Here is a minimal example:

1<?xml version="1.0" encoding="utf-8" ?>
2<configuration>
3  <appSettings>
4    <add key="ApiBaseUrl" value="https://api.example.com" />
5    <add key="RetryCount" value="3" />
6  </appSettings>
7
8  <connectionStrings>
9    <add
10      name="MainDb"
11      connectionString="Server=.;Database=Demo;Trusted_Connection=True;"
12      providerName="System.Data.SqlClient" />
13  </connectionStrings>
14</configuration>

The file is meant for configuration, not for logic. That separation makes deployment and environment changes easier to manage.

Read Settings From C#

In classic .NET Framework projects, ConfigurationManager is the normal API for reading App.config values.

1using System;
2using System.Configuration;
3
4class Program
5{
6    static void Main()
7    {
8        string apiBaseUrl = ConfigurationManager.AppSettings["ApiBaseUrl"];
9        string retryCount = ConfigurationManager.AppSettings["RetryCount"];
10
11        Console.WriteLine(apiBaseUrl);
12        Console.WriteLine(retryCount);
13    }
14}

For connection strings:

1using System;
2using System.Configuration;
3
4class Program
5{
6    static void Main()
7    {
8        var conn = ConfigurationManager.ConnectionStrings["MainDb"];
9        Console.WriteLine(conn.ConnectionString);
10    }
11}

In SDK-style projects targeting newer .NET, you may need the System.Configuration.ConfigurationManager package if you still want to use this configuration style.

When App.config Is a Good Fit

App.config works well for settings that differ by environment or deployment but are not supposed to be hard-coded. Typical examples are:

• file paths
• API base URLs
• log levels
• connection strings
• timeout values

This is especially useful in older Windows desktop or service applications where App.config is the conventional configuration mechanism.

Update Settings Without Recompiling

One of the main benefits is operational flexibility. If a test environment uses a different database or service URL, the deployed .config file can be changed without rebuilding the executable.

That does not mean every setting should be editable by hand, but it is often better than recompiling an app just to change a server name.

Keep Secrets Out of Plain Text When Possible

A frequent misuse of App.config is storing passwords or API secrets in plain text. Technically it works, but it is weak operational practice.

Safer options include:

• Windows-integrated authentication
• environment-specific secret stores
• encryption of protected configuration sections

If a value is sensitive, treat App.config as a distribution convenience, not as a secure vault.

App.config Versus Modern .NET Configuration

In newer .NET applications, especially ASP.NET Core and modern worker services, appsettings.json and the generic host configuration stack are more common. That does not make App.config useless. It just means App.config belongs mostly to traditional .NET Framework-style application models.

So a practical rule is:

• use App.config in classic .NET Framework app types that already expect it
• use the newer configuration system in modern .NET applications

Knowing that distinction prevents confusion when switching between older and newer .NET codebases.

Common Pitfalls

The biggest mistake is assuming App.config is automatically the same file name in the build output; the deployed file is usually renamed to match the executable. Another is hard-coding configuration values in code and then adding App.config later only partially, which defeats the purpose of centralized settings. Developers also put secrets into plain text configuration files without thinking about deployment security. Finally, teams moving between .NET Framework and modern .NET sometimes expect App.config to be the preferred mechanism everywhere, even though newer application models often use appsettings.json instead.

Summary

• 'App.config is the traditional XML configuration file for many .NET Framework applications.'
• It commonly stores appSettings, connectionStrings, and runtime configuration.
• Code usually reads it through ConfigurationManager.
• The build output produces an executable-specific .config file.
• 'App.config is useful for values that should change without recompiling the app.'
• Avoid storing sensitive secrets in plain text configuration files when better options exist.