Introduction

In a .NET application, the active configuration file at runtime is not the source app.config sitting in the project root. During build, it becomes an executable-specific config file such as MyApp.exe.config. If you need the actual file path in code, use the runtime configuration APIs rather than guessing from the project layout.

Understand Which File Is Actually Active

In classic .NET Framework projects, app.config is copied and renamed next to the executable. For example:

• source file in project: app.config
• runtime file: bin/Debug/MyApp.exe.config

That means “find the path of app.config” really means “find the path of the runtime configuration file currently loaded by this application domain.”

The most direct way to get that path is through AppDomain.

Use AppDomain.CurrentDomain.SetupInformation.ConfigurationFile

This is the simplest and most reliable answer for many desktop and console apps.

1using System;
2
3class Program
4{
5    static void Main()
6    {
7        string configPath = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile;
8        Console.WriteLine(configPath);
9    }
10}

This returns the active configuration file path being used by the current application domain.

If your goal is logging or diagnostics, this property is usually the right choice.

Use ConfigurationManager When You Also Need the Loaded Configuration

If you need both the path and the parsed configuration object, open the executable configuration explicitly.

1using System;
2using System.Configuration;
3
4class Program
5{
6    static void Main()
7    {
8        Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
9
10        Console.WriteLine(config.FilePath);
11        Console.WriteLine(config.AppSettings.Settings["Environment"]?.Value);
12    }
13}

This is useful when you need to inspect sections, app settings, or connection strings as well as the file location.

Distinguish Executable Directory from Config File Path

A common but incomplete pattern is building the path manually from the base directory and executable name.

1using System;
2using System.IO;
3
4string exeDir = AppDomain.CurrentDomain.BaseDirectory;
5string exeName = AppDomain.CurrentDomain.FriendlyName;
6string configPath = Path.Combine(exeDir, exeName + ".config");
7
8Console.WriteLine(configPath);

This often works, but it is still an inferred path. Prefer the runtime-provided configuration path when possible, especially if hosting or custom setup could change resolution behavior.

Handle Unit Tests and Hosted Environments Carefully

In unit tests, Windows services, or hosted applications, the active config file may not be the one you expect from local development.

For example:

• test runners may use testhost.dll.config or runner-specific config
• Windows services may load config from the deployed service executable path
• plugins or secondary AppDomain instances may have different config files

That is exactly why SetupInformation.ConfigurationFile is better than hard-coded assumptions.

If you create a new application domain manually, it can have its own config:

1using System;
2
3var setup = new AppDomainSetup
4{
5    ApplicationBase = AppDomain.CurrentDomain.BaseDirectory,
6    ConfigurationFile = "CustomDomain.config"
7};
8
9AppDomain domain = AppDomain.CreateDomain("Custom", null, setup);
10Console.WriteLine(domain.SetupInformation.ConfigurationFile);

In those cases, “active config” is domain-specific.

Read a Custom Section Once You Have the Path

Finding the path is often only step one. You may want to confirm the app is really reading the expected file.

1using System;
2using System.Configuration;
3
4class Program
5{
6    static void Main()
7    {
8        var config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
9
10        Console.WriteLine("Config path: " + config.FilePath);
11
12        foreach (string key in config.AppSettings.Settings.AllKeys)
13        {
14            Console.WriteLine($"{key} = {config.AppSettings.Settings[key].Value}");
15        }
16    }
17}

This is a practical diagnostic pattern when configuration values differ between environments.

.NET Core and Modern .NET Note

Modern .NET applications often use appsettings.json instead of app.config. If your project is on .NET Core or .NET 5 and later and uses the generic host, the active configuration model is different.

This article applies to app.config and ConfigurationManager style applications. If you are using Host.CreateDefaultBuilder, you should inspect the configured providers instead of looking for an .exe.config file.

Common Pitfalls

One common mistake is trying to locate the original project-root app.config file at runtime. The application normally uses the copied runtime config next to the executable instead.

Another issue is constructing the path manually and assuming it always matches the active configuration. That can break in tests, hosted apps, or custom application-domain scenarios.

A third mistake is forgetting that modern .NET projects may use JSON-based configuration rather than app.config.

Summary

• The runtime config file is usually not the original source app.config.
• 'AppDomain.CurrentDomain.SetupInformation.ConfigurationFile is the most direct way to get the active config path.'
• 'ConfigurationManager.OpenExeConfiguration is useful when you need both the path and loaded settings.'
• Avoid hard-coded assumptions about executable layout in hosted or test environments.
• Verify which configuration system your project actually uses before debugging path issues.