Environments & Feature Flags
`Hosting environment: Production` prints in the startup log, even in an app you never configured. That one string decides which settings file loads on top of the base and which branch of your code runs.
- ▸An environment you never set is not neutral: unset resolves to
Production, the hardened profile, notDevelopment. - ▸A frozen deploy-time string cannot flip one feature mid-run; a value re-read every request can, which is why both exist.
- ▸Nothing enforces a fixed set of environments: a check like
EnvironmentName == "QA"branches on any name you invented.
ASPNETCORE_ENVIRONMENT holds exactly one string, and its whole job is to name where the app thinks it is running. Set it and read it back on startup:
export ASPNETCORE_ENVIRONMENT=Development dotnet run # info: Microsoft.Hosting.Lifetime[0] # Hosting environment: Development
Leave it unset and the app does not fail, and it does not quietly pick Development. It falls back to Production:
dotnet run # info: Microsoft.Hosting.Lifetime[0] # Hosting environment: Production
Two facts are worth pinning down. First, the value is an arbitrary string. Development, Staging, and Production are conventions the host provides, but ASPNETCORE_ENVIRONMENT=QA is equally valid and gives you an environment named QA. Second, the value is resolved once, as the app starts, and cannot change while the process runs. DOTNET_ENVIRONMENT names the same thing for non-web apps; when both are set the web host reads them in a fixed order. Everything else in this topic keys off this one frozen string.