Understanding App.config and Web.config in .NET

In the Microsoft .NET ecosystem, app.config and web.config are standard XML-based configuration files used to manage application behavior, environment variables, security settings, and external dependencies without modifying or recompiling the source code. This article explains the distinct purposes of these files, their core structural elements, and how they function to provide flexible, environment-specific configuration across desktop, service, and web-based .NET applications.

What Are Configuration Files in .NET?

Configuration files in .NET allow developers to decouple application settings from compiled code. By storing parameters such as database connection strings, API keys, and runtime behaviors in plain text XML, administrators and developers can alter application behavior across different environments (such as Development, Staging, and Production) simply by modifying the XML file.

Differences Between App.config and Web.config

While both files share a common XML schema and fundamental purpose, they target different application models:

• app.config (Desktop, Console, and Service Applications): Used in non-web projects such as Windows Forms, WPF, Console Applications, and Windows Services. When the project is compiled, the build engine automatically renames app.config to [YourExecutableName].exe.config and places it in the output directory alongside the compiled binary.
• web.config (ASP.NET Web Applications): Specifically designed for ASP.NET applications hosted in Internet Information Services (IIS) or IIS Express. Unlike app.config, web.config is evaluated at runtime directly by IIS and ASP.NET. It remains named web.config in the root (or subdirectories) of the web application and can configure both the ASP.NET runtime and IIS web server pipeline.

Primary Uses and Core Sections

Both files use predefined XML nodes to control various aspects of the .NET runtime:

1. Application Settings (<appSettings>)

Stores custom, key-value pairs that can be read programmatically via the ConfigurationManager class. These are commonly used for feature flags, external API endpoints, and operational thresholds.

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

2. Database Connection Strings (<connectionStrings>)

Provides a centralized repository for database connection parameters. This isolates sensitive connection information and database provider definitions from business logic.

<connectionStrings>
  <add name="MainDatabase" 
       connectionString="Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;" 
       providerName="System.Data.SqlClient" />
</connectionStrings>

3. Assembly Binding and Redirection (<runtime>)

Controls how the .NET Common Language Runtime (CLR) locates and loads dependent assemblies (DLLs). If different libraries depend on different versions of the same shared assembly, binding redirects can map older version requests to a newer installed version.

4. Web Server and Pipeline Settings (<system.web> and <system.webServer>)

Exclusive primarily to web.config, these sections configure: * Authentication and Authorization: Secures pages and defines access rules (e.g., Windows Authentication, Forms Authentication). * Custom Errors: Configures HTTP error redirects (e.g., 404, 500 pages). * Modules and Handlers: Manages custom HTTP request processing logic inside IIS. * Session State: Configures how and where user sessions are stored (InProc, StateServer, or SQL Server).

Modern .NET Context (.NET Core and .NET 5+)

In modern .NET (.NET Core, .NET 6, .NET 8, and newer), the configuration system has largely transitioned to JSON-based files, primarily appsettings.json, managed by the generic host and the Microsoft.Extensions.Configuration framework.

However, web.config is still utilized in modern ASP.NET Core applications when hosted on Windows IIS to configure the ASP.NET Core Module (ANCM) reverse proxy settings, and both XML files remain foundational to legacy .NET Framework systems worldwide.