How to configure C# .Net Core apps for multiple Environments on same machine

Question

I have read the Microsoft doco on this, and a spent lot of time reading online discussions/questions/answers, and I have the below working, but would like to understand it properly before I start deploying various versions to other machines.

(simplified) I have a trio of apps: 1) a Windows Service, 2) a WebApi App and 3) a MVC Web app, that all work together. On the same machine as development is ongoing I need to deploy a set of these as a Demo version/environment, and another trio as Test environment. Some doco talks of setting/changing DOTNET_ENVIRONMENT and some talk of ASPNETCORE_ENVIRONMENT.

e.g. in profiles some say:

    "DataProcessorTest": {
      "commandName": "Project",
      "launchBrowser": true,
      "environmentVariables": {
        "DOTNET_ENVIRONMENT": "Test"
      },

and others say:

    "DataProcessorTest": {
      "commandName": "Project",
      "launchBrowser": true,
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Test"
      },

Q1. Is not the scope of DOTNET_ENVIRONMENT the entire machine? From what I have read, changing DOTNET_ENVIRONMENT changes the environment setting for ALL .net apps on the machine which if true is absolutely fraught with risks, especially if other apps come along later and start changing it as well.

Q2. What exactly is the scope of ASPNETCORE_ENVIRONMENT? Is it just this app itself? application pool? or wider as it seems to imply?

Q3. Where/What is if (!app.Environment.IsDevelopment()) specifically checking? Sometimes when Im using my Dev profile it is false' and sometimes my Testprofile it istrue`??

Q4. If I also have Test and Demo profiles, how do I (can I?) get if (!app.Environment.IsTest()) or if (!app.Environment.IsDemo()) somehow? Or are these hardcoded in?

This all used to be so simple and under the Framework. It seems another thing Microsoft have massively over engineered and made stupidly complex. (sorry, my 30+yr MS developer opinion having been here many times before). Maybe its just me.

I also have to wonder why Microsoft would build in Development, Staging and Production environments, but no Testing? Anyone who has worked in commercial software development knows they may occasionally be Staging (usually not), but will ALWAYS need Testing.

Answer 1

For ASP.Net Core applications, use "ASPNETCORE_ENVIRONMENT". For non-ASP runtimes, use "DOTNET_ENVIRONMENT". Most likely you have looked at similar documents scoped to the different runtimes.

The scope of these environment variables is entirely dependent on where you define them. If you are setting these variables at the machine level, then you would be setting these machine-wide, which doesn't sound like it matches your use case at all.

It is common to use these variables during development in your launchSettings.json file as described in this post: how do launchSettings.json and appSettings.json work? but also in the docs here: Use multiple environments in ASP.NET Core

By changing this setting, to any value that you have a corresponding configuration, you can switch the pre-configured appSettings file to use.

You can then use hostingContext.HostingEnvironment.EnvironmentName to get the value of the setting, then you can use that to load the specific appSettings file. The following snippet loads the appSettings.json file by default, then overrides with the content from the file that matches the environmentName:

var env = hostingContext.HostingEnvironment;
var sharedFolder = Path.GetFullPath(env.ContentRootPath);
config.AddJsonFile(Path.Combine(sharedFolder, "appsettings.json"), optional: true, reloadOnChange: true)
      .AddJsonFile(System.IO.Path.Combine(sharedFolder, $"appsettings.{env.EnvironmentName}.json"), optional: true);

In some respects this is actually simpler than it used to be, but now the functionality is standard across all deployment types and runtimes. In the past the environment versions of web.config were only utilised as part of the publishing and deployment process, now we have a standard behaviour that we can deploy into many different environments without pre-compiling or modifying the configuration file, meaning we can deploy the exact same deployment image to different environments and not make changes to any files inside the image itself.

IsDevelopment(), IsProduction(), IsStaging() are provided as common options to get you going quickly. In CI/CD you may not have a Testing environment at all, you might be evaluating the staging environment to swap into production. If you need additional environments, then please use the IsEnvironment("insertEnvironmentNameHere") method to check if the host environment name matches "insertEnvironmentNameHere" or retrieve the environment name directly as I have shown above, you can use any arbitrary name for the environment that you choose to support.

It is my understanding that the default options of Development,Production,Staging are to specifically align with current advice for configuring pipeline deployments and CI/CD