Consequences of custom environment names in ASP.NET Core web applications

Question

I've been trying to find what (if any) are the consequences of configuring the ASPNETCORE_ENVIRONMENT variable to anything other than Production in a production deployment.

We use the environment variable to load different appSettings configurations depending on our deployment target, and we aren't sure if there are any critical optimization that are done behind the scenes when you set the environment to Production.

I know that if you don't set the variable it defaults to Production but that's pretty much it...

Is the source coded in a way that it just always checks against the Environment.IsDevelopment method rather than the Environment.IsProduction method so that setting it to whatever else doesn't really matter in terms of release optimizations?

Thank you in advance!

Answer 1

No, nothing is done magically for you behind the scenes. Well, almost: WebApplication.CreateBuilder does preconfigure some defaults for you for the Development environment. But otherwise, it's just conventions. An environment is just a name for a set of configuration values, after all.

Here are the recommendations written in the documentation:

The development environment can enable features that shouldn't be exposed in production. For example, the ASP.NET Core project templates enable the Developer Exception Page in the development environment. Because of the performance cost, scope validation and dependency validation only happens in development.

[...]

 The production environment should be configured to maximize security, performance, and application robustness. Some common settings that differ from development include:

• Caching.
• Client-side resources are bundled, minified, and potentially served from a CDN.
• Diagnostic error pages disabled.
• Friendly error pages enabled.
• Production logging and monitoring enabled. For example, using Application Insights.

So, for example, the default template does that configuration for you when you generate a new project, but you can always change that. A third party library you're using might be configuring itself automatically based on the current environment, but in practice it's often better to just provide configuration points and let you do the environment switch yourself.

Ultimately, most of the optimisation will be done by the C# compiler when compiling in release, and also by the JIT when your app is executed. An ASP.NET app is still a .NET app, after all, and it runs on the same runtime.

As for the "known" environments, they correspond to the fields of the Microsoft.Extension.Hosting.Environments class. But you could use any value, really.