How to Read app.config and web.config Settings in .NET Class Libraries

By the end of this page, you will understand how configuration works for .NET class libraries, why ConfigurationSettings is deprecated, how to use ConfigurationManager.AppSettings, and why class libraries usually read configuration from the host application's config file rather than their own separate config file.

In .NET, a class library does not usually own the application configuration file. The configuration belongs to the host application that loads the library.

That means:

• A Windows Forms app typically uses app.config
• An ASP.NET app typically uses web.config
• Your DLL reads from whichever configuration file belongs to the running application

The important idea is that your library usually does not need to know whether the host is web or desktop. It simply reads configuration through the .NET configuration API, and the runtime resolves the correct host config source.

Older code often uses:

ConfigurationSettings.AppSettings.Get("MySetting")

This API is deprecated. The recommended API in classic .NET is:

ConfigurationManager.AppSettings["MySetting"]

If ConfigurationManager is not available, the usual reason is that your project is missing a reference to the configuration assembly/package.

In classic .NET Framework projects, you typically add a reference to:

System.Configuration

Then import the namespace:

using System.Configuration;

After that, your class library can read values from the host application's configuration.

Think of a class library as a tool used inside a larger machine.

• The application is the machine
• The config file is the machine's settings panel
• The class library is one tool inside the machine

The tool does not carry its own main settings panel. Instead, it reads the settings of the machine that is currently using it.

So if your DLL is loaded by:

• a web app, it reads the web app's configuration
• a desktop app, it reads the desktop app's configuration

Your library asks the runtime, "What are the current application settings?" It does not normally ask, "Am I in a web app or a Windows app?"

The usual approach in a .NET Framework class library is:

using System.Configuration;

public class SettingsReader
{
    public string GetMySetting()
    {
        return ConfigurationManager.AppSettings["MySetting"];
    }
}

Required configuration entry

For a desktop app (app.config) or web app (web.config):

<configuration>
  <appSettings>
    <add key="MySetting" value="Hello from config" />
  </appSettings>
</configuration>

Example with a null check

using System;
using System.Configuration;

public class SettingsReader
{
    public  ()
    {
          = ConfigurationManager.AppSettings[key];

         (.IsNullOrEmpty())
        {
              InvalidOperationException();
        }

         ;
    }
}

Consider this code:

using System;
using System.Configuration;

public class SettingsReader
{
    public void PrintSetting()
    {
        string value = ConfigurationManager.AppSettings["MySetting"];

        if (value == null)
        {
            Console.WriteLine("Setting not found.");
            return;
        }

        Console.WriteLine(value);
    }
}

And this config:

<appSettings>
  <add key="MySetting" value="Blue" />
</appSettings>

Step by step:

1. The application starts.
2. The .NET runtime loads the host application's configuration file.
3. Your class library method PrintSetting() runs.
4. ConfigurationManager.AppSettings["MySetting"] looks in the host config's <appSettings> section.

Configuration settings are used everywhere in real applications.

API base URLs

<appSettings>
  <add key="ApiBaseUrl" value="https://api.example.com" />
</appSettings>

A library that calls external services can read this value.

Feature flags

<appSettings>
  <add key="EnableCaching" value="true" />
</appSettings>

A library can enable or disable behavior based on a setting.

File paths

<appSettings>
  <add key="LogFolder" value="C:\Logs" />
</appSettings>

Useful for export tools, logging helpers, or report generators.

Timeouts and limits

In real projects, developers often go beyond directly reading AppSettings everywhere.

Common pattern: wrap configuration access

Instead of scattering calls to ConfigurationManager.AppSettings throughout the codebase, developers often centralize it:

using System;
using System.Configuration;

public static class AppConfig
{
    public static string GetRequired(string key)
    {
        string value = ConfigurationManager.AppSettings[key];

        if (string.IsNullOrWhiteSpace(value))
        {
            throw new InvalidOperationException($"Missing configuration value: {key}");
        }

        return value;
    }
}

This improves:

• validation
• consistency
• testability
• error messages

Guard clauses

A common practice is to fail early if config is missing:

1. Forgetting to add the assembly/package reference

If this fails to compile:

ConfigurationManager.AppSettings["MySetting"];

you may be missing:

• the System.Configuration reference in .NET Framework
• or the System.Configuration.ConfigurationManager package in newer projects

2. Forgetting the namespace

Broken code:

public class Test
{
    public string Read()
    {
        return ConfigurationManager.AppSettings["MySetting"];
    }
}

Fix:

using System.Configuration;

3. Assuming the library has its own active config file

Beginners sometimes expect the DLL to automatically use a separate config file. Usually it does not. It reads from the host application's config.

4. Not handling missing keys

Broken code:

 name = ConfigurationManager.AppSettings[];
Console.WriteLine(name.Length);

ConfigurationSettings vs

using System.Configuration;

string value = ConfigurationManager.AppSettings["MySetting"];

Config entry

<configuration>
  <appSettings>
    <add key="MySetting" value="Hello" />
  </appSettings>
</configuration>

Key points

• ConfigurationSettings is deprecated
• Use ConfigurationManager.AppSettings[key]
• Add reference to System.Configuration in .NET Framework
• In newer projects, you may need the System.Configuration.ConfigurationManager package
• A class library usually reads from the host application's config file
• AppSettings values are always strings
• Missing keys return null

Safe read pattern

How does a class library know whether to use app.config or web.config?

It usually does not need to know. The .NET runtime uses the configuration file of the host application that loads the library.

Why is ConfigurationManager missing in my class library?

Your project is likely missing the required reference or package. In .NET Framework, add System.Configuration. In newer projects, install System.Configuration.ConfigurationManager.

Is ConfigurationSettings.AppSettings.Get() still usable?

It may still work in older projects, but it is deprecated. Prefer ConfigurationManager.AppSettings[...].

Can a DLL have its own separate config file?

Not in the usual automatic way people expect. Typically, the active configuration comes from the host application, not the DLL itself.

What happens if a setting key does not exist?

ConfigurationManager.AppSettings[key] returns null, so your code should handle that safely.

Are app settings strongly typed?

No. Values from AppSettings are strings. You must parse them into int, bool, or other types yourself.

• appSettings — The configuration section commonly used for simple key-value settings.
• connectionStrings — Another built-in config section for database connection information.
• ConfigurationManager — The main API for reading classic .NET configuration values.
• Dependency injection — A cleaner way to pass settings into libraries instead of reading config directly.
• IConfiguration — The modern .NET configuration abstraction used with appsettings.json and environment variables.
• Null checking — Important because missing config keys return null.
• Type conversion — Needed because config values are read as strings.
• Guard clauses — Useful for failing early when required configuration is missing.