Styjun

I've read a bit of documentation regarding setting up environments for deployment of ASP.Net Core applications. These articles usually reference Development. Staging and Production by name, but never deviate from these traditional environment names.

Usually, once you are out of "development", you want to turn off development/debugging settings so that sensitive information isn't leaked out onto the web in case your application crashes. This makes sense.

However, my application is in the early stages of development and I am in need of two development environment configurations that we can debug. Specifically, my team will largely want to develop locally, connecting to a local SQL Server database. However, we need to setup and test an Azure database and for preliminary setup, it would help if we could run the server development mode, locally, and be able to connect to our Azure databases from our dev boxes.

What I would like to do is create two config files named aspsettings.Development.json and aspsettings.LocalDevelopment.json, both of which are in my two ASP.Net core projects within my solution-- one for Web API and the other for the UI project.

Development will contain all values for connecting to the proper dev database servers (the Azure database used for development testing needing access to Azure) and the LocalDevelopment environment will be used for connecting to the local database.

I've added these files to my project, copied out the Development details to LocalDevelopment and changed just the connection strings for the API project config.

Next, I opened up my projects properties and added two profiles for debugging. As an attempt at figuring this out, I created these identical profiles for both the API project and the UI project. These profiles were named "IIS Local" and the other "IIS Dev Server". Finally, in each project page for each new profile, I entered their respective values for ASPNETCORE_ENVIRONMENT-- Development and LocalDevelopment.

When I debug the application as Development, it works fine. However, when I run the application using theLocalDevelopment` environment and profile, I'm getting the following error:

Error. An error occurred while processing your request. Request ID: 0HLLE04D5NFDU:00000001

Development Mode Swapping to Development environment will display more
detailed information about the error that occurred.

Development environment should not be enabled in deployed
applications, as it can result in sensitive information from
exceptions being displayed to end users. For local debugging,
development environment can be enabled by setting the
ASPNETCORE_ENVIRONMENT environment variable to Development, and
restarting the application.

This doesn't seem to make since because both configs are the same for their respective projects and the only differences are the connections strings in the API and, I did add an EnvironmentName property for identification.

What might I be doing wrong?

Here are the contents of the LocalDevelopment file. Just in case I'm missing something.

Settings in the API

 "Logging": 
 "LogLevel": 
 "Default": "Debug",
 "System": "Information",
 "Microsoft": "Information"
 
 ,
 "EnvironmentName": "LOCAL",
 "ConnectionStrings": 
 "Database": "xxx"
 

Settings in the UI

 "Logging": 
 "LogLevel": 
 "Default": "Debug",
 "System": "Information",
 "Microsoft": "Information"
 
 

In your Startup.cs, you likely have something like the following in your Configure method:

if (env.IsDevelopment())

 app.UseDeveloperExceptionPage();
 app.UseDatabaseErrorPage();

else

 app.UseExceptionHandler("/error/500");

You need to change the conditional to be something like:

if (env.IsDevelopment() || env.IsEnvironment("LocalDevelopment"))

Or you can simply make any environment that's not production using the development error pages:

if (!env.IsProduction())

The methods like IsDevelopment, IsProduction, etc. are just syntactic sugar so you don't have to do IsEnvironment("Development"). However, since LocalDevelopment is of your own creation, there's obviously not a method built-in for that.