Introduction

In a WPF application, App.config is the traditional place to store simple settings, connection strings, and custom configuration sections. At build time it becomes YourApp.exe.config, and the usual runtime entry point for reading it is ConfigurationManager.

Start With A Simple appSettings Section

For basic key-value settings, appSettings is enough:

1<configuration>
2  <appSettings>
3    <add key="AppTitle" value="My WPF Application" />
4    <add key="MaxRetries" value="3" />
5    <add key="ApiBaseUrl" value="https://api.example.com" />
6  </appSettings>
7
8  <connectionStrings>
9    <add name="DefaultConnection"
10         connectionString="Server=localhost;Database=MyDb;Trusted_Connection=True;"
11         providerName="System.Data.SqlClient" />
12  </connectionStrings>
13</configuration>

This file lives in the project as App.config, but the running program reads the generated .exe.config copy in the output directory.

Read Values With ConfigurationManager

For .NET Framework WPF apps, ConfigurationManager is the usual API. In newer .NET versions, you may need the System.Configuration.ConfigurationManager package.

1using System;
2using System.Configuration;
3
4string title = ConfigurationManager.AppSettings["AppTitle"] ?? "Default Title";
5
6int maxRetries = int.TryParse(
7    ConfigurationManager.AppSettings["MaxRetries"],
8    out var retries
9) ? retries : 3;
10
11Console.WriteLine(title);
12Console.WriteLine(maxRetries);

This pattern is fine for small applications, but once several settings are used repeatedly, a wrapper class usually reads better.

Create A Strongly Typed Wrapper

Instead of scattering raw string keys across the codebase, centralize configuration access:

1using System;
2using System.Configuration;
3
4public static class AppConfig
5{
6    public static string AppTitle =>
7        ConfigurationManager.AppSettings["AppTitle"] ?? "WPF App";
8
9    public static int MaxRetries =>
10        int.TryParse(ConfigurationManager.AppSettings["MaxRetries"], out var value) ? value : 3;
11
12    public static string ApiBaseUrl =>
13        ConfigurationManager.AppSettings["ApiBaseUrl"] ?? "https://localhost";
14
15    public static string ConnectionString =>
16        ConfigurationManager.ConnectionStrings["DefaultConnection"]?.ConnectionString
17        ?? throw new InvalidOperationException("Missing DefaultConnection");
18}

This avoids magic strings in your view models and services.

Use It Naturally In WPF And MVVM

Configuration values are often consumed in the startup path or view models:

1public class MainViewModel
2{
3    public string WindowTitle { get; } = AppConfig.AppTitle;
4    public string ApiBaseUrl { get; } = AppConfig.ApiBaseUrl;
5}

That makes configuration part of the application's bootstrapping logic instead of an ad hoc concern spread throughout the UI.

Connection Strings And Custom Sections

For database access, use the connectionStrings section rather than stuffing connection data into ordinary appSettings.

1using System.Configuration;
2
3string connectionString =
4    ConfigurationManager.ConnectionStrings["DefaultConnection"]?.ConnectionString
5    ?? throw new InvalidOperationException("Connection string not found");

If your configuration grows more complex, you can define a custom configuration section type. That is still a valid App.config pattern in classic WPF applications, although many teams stop at appSettings plus connection strings unless the structure becomes genuinely complicated.

Know The Runtime File You Are Actually Editing

One source of confusion is that editing App.config while the application is already running does not magically change the in-memory values. The running process reads YourApp.exe.config, and values are cached. If you modify the config at runtime, you need to update the executable configuration file and refresh the relevant section.

That is why App.config is best treated as deployment-time configuration rather than a general user settings database. For per-user mutable settings, the built-in settings designer or application data storage is often a better fit.

Common Pitfalls

• Editing App.config in the project and expecting the running executable to reread it automatically.
• Scattering raw configuration key strings across the codebase instead of wrapping them once.
• Putting connection strings into appSettings instead of the dedicated connectionStrings section.
• Storing secrets in plain text configuration files that ship beside the executable.
• Treating App.config as a user preferences store when the values are really application-level settings.

Summary

• 'App.config is the classic XML configuration file for WPF applications.'
• Read simple values with ConfigurationManager.AppSettings and connection strings with ConfigurationManager.ConnectionStrings.
• Wrap configuration access in a typed helper so WPF and MVVM code stays clean.
• Remember that the runtime file is the generated .exe.config, not the source project file itself.
• Write settings at runtime with OpenExeConfiguration + Save + RefreshSection.
• For .NET 6+ WPF apps, consider appsettings.json with IConfiguration as the modern alternative.