Introduction

Changing app.config at runtime is possible in classic .NET configuration scenarios, but it is easy to misunderstand what that actually changes. In .NET Framework applications, app.config is copied to the output directory as yourapp.exe.config, and many settings are read at startup or cached by the framework. That means editing the file on disk does not automatically update every configuration value already loaded into memory.

So the practical answer is two-part: yes, you can write updated values to the configuration file, but no, you should not assume every part of the running application will instantly start using them. For truly dynamic settings, a separate configuration store is often a better design.

Update Settings With ConfigurationManager

In .NET Framework, the standard API for editing the executable configuration file is ConfigurationManager.OpenExeConfiguration.

1using System;
2using System.Configuration;
3
4class Program
5{
6    static void Main()
7    {
8        Configuration config = ConfigurationManager.OpenExeConfiguration(
9            ConfigurationUserLevel.None
10        );
11
12        config.AppSettings.Settings["Theme"].Value = "Dark";
13        config.Save(ConfigurationSaveMode.Modified);
14        ConfigurationManager.RefreshSection("appSettings");
15
16        string theme = ConfigurationManager.AppSettings["Theme"];
17        Console.WriteLine(theme);
18    }
19}

This updates the executable configuration file and refreshes the appSettings section for code that reads through ConfigurationManager.AppSettings afterward.

If the key does not exist yet, add it before saving:

1if (config.AppSettings.Settings["Theme"] == null)
2{
3    config.AppSettings.Settings.Add("Theme", "Dark");
4}
5else
6{
7    config.AppSettings.Settings["Theme"].Value = "Dark";
8}

Know What Changes Immediately and What Does Not

Refreshing a configuration section helps for code that reads that section lazily through ConfigurationManager. It does not guarantee that every framework component or every library will reload its own cached settings.

For example, if you read a connection string once during startup and keep it in a singleton service, editing the config file later will not change that already-copied value.

That is why runtime config editing works best for:

• simple app settings read on demand
• infrequent administrative changes
• desktop utilities that can tolerate restart semantics

It is a weaker fit for highly dynamic feature flags or live infrastructure settings.

Separate “Change the File” From “Change Running Behavior”

A lot of confusion comes from treating these as the same operation.

Changing the file means persisting a new value for future reads or future launches. Changing running behavior means all relevant components in the current process start using the new value immediately.

Those are not the same thing.

If you need guaranteed live updates without restart, consider storing the setting somewhere designed for runtime refresh, such as:

• a database table
• an external config service
• environment-specific configuration reloaded by your own code
• user-scoped settings instead of application-scoped settings

app.config Versus Modern .NET Configuration

This topic is mostly about .NET Framework and compatibility-style configuration APIs. In modern .NET, appsettings.json and Microsoft.Extensions.Configuration are the common configuration model.

That does not mean App.config disappears everywhere, but it does mean you should be careful about which runtime model your application actually uses. If the project is on .NET 6 or later and still relies on ConfigurationManager, that is usually compatibility-driven rather than the primary modern pattern.

Be Careful in Multi-User or Multi-Process Scenarios

Editing a shared configuration file at runtime can create operational problems.

If multiple processes touch the same file, the last writer wins. If the app runs with limited permissions, save operations may fail. If a crash happens mid-write, you may leave the config in an inconsistent state.

For that reason, runtime config file editing should be deliberate and rare. It is not a great substitute for a proper settings workflow.

Common Pitfalls

The biggest mistake is assuming that writing to app.config instantly updates every part of a running program. It usually does not.

Another issue is editing the source App.config in the project and expecting the running executable to watch it. The running app actually uses the deployed output config file.

A third problem is using this approach for highly dynamic settings when a database, external config source, or user settings store would be more reliable.

Summary

• In .NET Framework apps, you can update config values with ConfigurationManager.OpenExeConfiguration.
• Saving the file and calling RefreshSection helps only for settings that are read again afterward.
• Changing the config file is not the same as updating all in-memory application behavior.
• 'App.config is mainly a classic .NET Framework pattern; modern .NET usually prefers appsettings.json.'
• For truly dynamic runtime settings, use a dedicated configuration store rather than rewriting the executable config file.