The gist: ASPNETCORE_ENVIRONMENT variables map directly to the appsettings.json files provided with the template by name. Such that appsettings.Development.json references the environment variable with the value “Development”.
When using Visual Studio to develop ASP.NET Core applications, you have access to Environment variables in the project property’s “Debug” tab.
This setting determines the way that ASP.NET applies your application’s configuration settings in that the value can impact which configuration file is used at a given time. One of the simplest things to note is that the value “Development” here corresponds to the filename annotation appsettings.Development.json. For example, by changing the value to “Production”, to indicate that you are running in a production environment, Visual Studio will look for both the appsettings.json file as well as a corresponding file, appsettings.Production.json at run time.
Why is this important?
When using environment dependent settings, you will want to ensure that when your application is deployed, the correct settings are loaded. It can guarantee expected behavior as well as act as a form of code security ensuring that no developer mode secrets are exposed by your production site. An easy example is the developer exception page.
During development, being able to see the stack trace and other debug information can be useful. However, if this is exposed by your production site then it could display some information about your site configuration and/or code structure that you wouldn’t want a potential hacker to see. Deploying your application in release mode will not prevent this because the environment variable ultimately determines which configuration file is read.
The code from the Startup.cs page below will read the value in the environment variable, which is currently “Development”, and load the developer error page.
The only way to prevent this without making any other changes is to change the value in the properties pane to Production or something else that would default the evaluation to false. In this case, I changed it to read “Home”.
If the value does not match or if the variable does not exist, in which case it is null, the expression will evaluate to false causing ASP.NET Core to skip loading the developer error page. As a result, a custom error page that I created was loaded as seen below.
was loaded as seen below.
I was able to trigger this error by adding treating the word “hacker” as invalid in the path using the code below. This code would not typically appear in your Startup.cs class.