ASP.NET - Environment Specific Configurations

Environment-specific configuration lets an app behave differently in development, staging and production. Settings such as keys, logging and error messages are separated so testing does not affect live systems.

Environment Names
ASP.NET Core uses three common names: Development, Staging and Production. Each environment activates its own rules. Development shows detailed errors, staging copies production behavior safely, and production hides internal details.

Configuration Files
Separate files such as appsettings.Development.json or appsettings.Production.json override values in appsettings.json. This keeps sensitive or tuned settings out of shared code and allows each deployment to control its own behavior without modifying source code.

Environment Variables
Environment values can be set outside the application at runtime. They decide which configuration file loads and may store secure values such as connection strings. This prevents exposing secrets in version control.

Conditional Code Paths
Middleware and services can activate only in certain environments. Development tools run only locally, while production may enable stricter security. This avoids wasted resources and protects live deployments.

Why It Matters
Environment configuration supports safety and flexibility. Teams can test changes confidently, deploy smoothly and protect sensitive settings while keeping the same source code everywhere.

Example

appsettings.Development.json

{
  "Logging": { "LogLevel": { "Default": "Debug" }},
  "FeatureX": { "Enabled": true }
}

appsettings.Production.json

{
  "Logging": { "LogLevel": { "Default": "Warning" }},
  "FeatureX": { "Enabled": false }
}

Program.cs

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

Console.WriteLine($"Env: {app.Environment.EnvironmentName}");
app.MapGet("/", () => $"Feature: {builder.Configuration["FeatureX:Enabled"]}");

app.Run();