Beware a bug in the latest Visual Studio – You may be debugging production

A small tale of caution when using Visual Studio 2019 and .NET Core – There is a bug present in the latest version whereby Visual Studio can unexpectedly ignore your environment variables with knock-on consequences.

I recently upgraded my version of Visual Studio 2019  to the latest (16.6.2) in order to resolve an issue with it repeatedly adding development environment variables to the web.config when debugging (and hence breaking production servers). 

Unfortunately that seems to have uncovered another bug ?

** UPDATE **

This issue has now been fixed in 16.6.3 here! Kudos to Microsoft for a speedy fix.

This cropped up on a .NET Core project I’m currently working on, whereby debugging an MVC solution on my machine would show me data from the production system.

Why is this happening?

Typically when working with .NET Core in Visual Studio you will use a launchSettings.json file to set the ASPNETCORE_ENVIRONMENT variable to “Development” so when running in IIS Express for example, your settings all use development parameters.

A typical launchsettings.json file:

"profiles": 
{    
  "IIS Express": 
  {      
    "commandName": "IISExpress",      
    "launchBrowser": true,      
    "environmentVariables": 
    {        
      "ASPNETCORE_ENVIRONMENT": "Development"      
    }    
}

Appsettings.json transforms are a common way of separating settings for different environments e.g. Development, Staging, Production. We typically do this by having a default appsettings.json file together with a bunch of environment specific appsettings.{Environment}.json files that will override the defaults depending on the current environment set.

Unfortunately in the latest version of Visual Studio 2019, if you have a web.config file present in your project then the environment variables set in launchsettings.json will be ignored and your environment will not be set correctly.

This means your environment specific appsettings.json will not be used and .NET core will use the settings in the default appsettings.json. In some instances this can include production settings. In Startup.cs env.IsDevelopment() will also incorrectly evaluate to false which could affect the middleware that gets run.

Steps to reproduce:

1. dotnet new mvc
2. dotnet new webconfig
3. uncomment the <location> section in web.config
4. debug the application using IISExpress

If like me, you’re working in a situation where you have network access to production servers from your development machine (probably not a good idea but possible with cloud servers and such like) you could inadvertently be connecting to production even though you are debugging your local solution.

This is obviously less than ideal if upgrading your tooling suddenly and unexpectedly runs the risk that developers could accidentally affect production data in some scenarios.

Workarounds that don’t work

1. Set the ASPNETCORE_ENVIRONMENT variable through a Windows environment variable to “Development” 
2. Add the following code before the HostBuilder code: 

#if DEBUG
	Environment.SetEnvironmentVariable("ASPNETCORE_ENVIRONMENT", "Development");
#endif

Unfortunately these workarounds don’t work as they set the environment to “Development” but the correct environment specific appsettings.json file is still not used.

Workarounds that do work

1. Remove the web.config if not needed
2. Move all your production settings out to their own appsettings.Production.json file for safety reasons and put your development settings in the appsettings.json file.

If you know a better and more sensible workaround until Microsoft release a bug fix please let me know!