When Done, You Will

Our Environment Setup

We are going to dispense with the Staging or Production Replica environment and use only Development and Production – this is more than sufficient to demonstrate the necessary concepts we need to cover. Refer to the following diagram to see my environmental setup (yours should mirror this to a large extent).

As you can see, the “components” that are there are effectively the same; it’s really only the underlying platform that is different (a local Windows PC vs. Microsoft Azure).

We’ll park further discussion on the Production Environment for now and come back to that in later chapters; for now, we’ll focus on our Development environment.

The Development Environment

How does our app know which environment it’s in? Quite simply – we tell it!

This is where “Environment Variables” come into play, specifically the ASPNETCORE_ENVIRONMENT variable. Environment variables can be specified, or set, in a number of different ways depending on the physical environment (Windows, OSX, Linux, Azure, etc.). So, while they can be set at the OS level, our discussion will focus setting them in the launchSettings.json file (this can be found in the Properties folder of your project) for now.

 Environment variables set in the launchSettings.json file will override environment variables set at the OS layer; that is why for the purposes of our discussion, we’ll just focus on setting out values in the launchSettings.json file.

A fuller discussion on multiple environments in ASP.NET Core can be found here.¹

Opening the launchSettings.json file in the API project; you should see something similar to the following.

In the preceding highlighted profile section, there are also additional details that are specified including the “applicationUrl” for both http and https and well as our environmentVariables; in this instance we only have one: ASPNETCORE_ENVIRONMENT , set to: Development.

For example, see Figure 8-3.

So What?

At this stage I hear you all saying, “Yeah that’s great and everything, but so what?”

Good question; I’m glad you asked that question!²

Therefore, depending on our environment, we’ll want to change our configuration.

I’m using the database connection string as an example here, but there are many other configurations that will change depending on the environment. That is why it is so important we are aware of our environment.

Make the Distinction

We’re going to go with option 2. While option 1 is a possibility (indeed this pattern is used in many of the default .NET Core Projects – see the following example), I personally prefer to decouple code from configuration where possible, although it’s not always possible – that is why we’ll go with option 2.

The preceding snippet is taken from our very own Startup class, where the default project template uses the IsDevelopment parameter to determine which exception page to use.

Order of Precedence

OK, so we’re going to leverage from the behavior of the .NET Core Configuration API to change the config as required for our two different environments (we’ve already made use of this when we configured the connection string for the DB Context).

Let’s quickly revisit the Program Class startup sequence for our app as covered in Chapter 4.

 It is really important to note here that The Last Key Loaded Wins.

What this means (and we’ll demonstrate this below) is that if we have two configuration items with the same name, for example, our connection string, PostgreSqlConnection, that appears in different configuration sources, for example, appsettings.json and appsettings.Development.json, the value contained in appsettings.Development.json will be used.

So, you’ll notice here that Environment Variables will take precedence over the values in appsettings.json. This is the opposite of how this works when we talk about launchSettings.json. As previously mentioned, the contents of launchSettings.json take precedence over our system-defined environment variables.

So be careful!

I’ve referenced a great Blog Post on the Order of Precedence with Configuring ASP.NET Core here,³ for a further overview.

It’s Time to Move

This means we will have the same configuration element in both appsettings.json and appsettings.Development.json .

Again, if you’re unsure that your JSON is well-formed, use something like http://jsoneditoronline.org/ to check.

Save the files you’ve made any changes to, run your API, and make the same call – it all still works as usual.

Let’s Break It

OK, so to prove the point we were previously making

• Stop your API from running (Ctrl + c).

• Go back into appsettings.Development.json file, and edit the Password parameter in the connection string so that authentication to the PostgreSQL Server will fail – see Figure 8-7.

• Save your file.

  

OK, now run the app again, and try to make the API Call.

Looking at the terminal output, you’ll see you get a database connection error; this is because the last value for our connection string was invalid.

Fix It Up

OK, so let’s fix this:

• Edit your appsettings.Development.json file, and correct the value for the Password parameter

• Delete the ConnectionStrings json from the appsettings.json file.

This means that only our appsettings.Development.json file now contains our connection string; your appsettings.json file should now look like that in Figure 8-9.

This means that currently, we only have a valid source for our connection string when running in a Development environment.

Learning Opportunity

What will happen if you edit the launchSettings.json file and change the value of ASPNETCORE_ENVIRONMENT to “Production”?

Do this, run your app, and explain why you get this result.

We will cover our Production connection string in the Chapter 13.

What Are User Secrets?

Well I gave you a bit of a clue in this chapter already.

This means that individual users can store (among other things) the credentials that they use to connect to a database. As the file is secured by the local file system, they remain secure (assuming no one has log-in access to your PC).

In terms of what you can store, this can be anything; it’s just string data. We’re now going to set up User Secrets for our development connection string.

Setting Up User Secrets

We need to make use of something called The Secret Manager Tool in order to make use of user secrets; this tool works on a project-by-project basis and therefore needs a way to uniquely identify each project. For this we need to make use of GUIDs.

Learning Opportunity

Find out what GUID stands for, and do a little bit of reading on what they are and where they can be used (assuming you don’t know this already!)

Cast your mind back to Chapter 2 where we set up our development lab, and one of the extensions we suggested for VS Code was Insert GUID – well now we get to use it!

In VS Code open your CommandAPI.csproj file, and in the <PropertyGroup> xml element, place the xml highlighted in the following:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>

    <TargetFramework>netcoreapp3.1</TargetFramework>

    <UserSecretsId></UserSecretsId>

  </PropertyGroup>

  <ItemGroup>

    <PackageReference Include="Microsoft.EntityFrameworkCore" Version="3.0.0" />

    .

    .

    .

</Project>

• Place your cursor in between the opening <UserSecretsId> and the closing </UserSecretsId> elements.

• Open the VS Code “Command Palette”:

  • Press F1

  • Or Ctrl + Shift + P

  • Or View ➤ Command Palette

• Type “Insert.”

Now save your file.

Deciding Your Secrets

Now we come to actually adding our secrets via The Secret Manager Tool, which will generate a secrets.json file.

Either will work, but I’m going to go with option 2 where we will store the individual components as “secrets.”

You should get a “Successfully saved UserID…” message.

Again, you should get a similar success message.

Where Are They?

So, on my machine, it can be found here.⁵

It’s just a simple, non-encrypted JSON file.

Code It Up

OK, so now to the really exciting bit where we’ll actually use these secrets to build out our full connection string.

Step 1: Remove User ID and Password

We want to remove the “offending articles” from our existing connection string in our appsettings.Development.json file.

So our appsettings.Development.json file should now contain only

{

  "Logging": {

    "LogLevel": {

      "Default": "Debug",

      "System": "Information",

      "Microsoft": "Information"

    }

  },

  "ConnectionStrings":

  {

    "PostgreSqlConnection":

      "Host=localhost;Port=5432;Database=CmdAPI;Pooling=true;"

  }

}

Make sure you save your file.

Step 2: Build Our Connection String

Move over into our Startup class, and add the following code to the ConfigureServices method (noting the inclusion of the new using statement at the top):

.

.

.

using Npgsql;

namespace CommandAPI

{

    public class Startup

    {

        public IConfiguration Configuration {get;}

        public Startup(IConfiguration configuration) => Configuration = configuration;

        public void ConfigureServices(IServiceCollection services)

        {

            var builder = new NpgsqlConnectionStringBuilder();

            builder.ConnectionString =

              Configuration.GetConnectionString("PostgreSqlConnection");

            builder.Username = Configuration["UserID"];

            builder.Password = Configuration["Password"];

            services.AddDbContext<CommandContext>

                (opt => opt.UseNpgsql(builder.ConnectionString));

            services.AddControllers();

            services.AddScoped<ICommandAPIRepo, SqlCommandAPIRepo>();

        }

.

.

.

Again, for clarity I’ve circled the new/updated sections below:

1. 1.

   We need to add a reference to Npqsql in order to use NpgsqlConnectionStringBuilder.

    
2. 2.
   This is where we

   1. a.

      Create a NpgsqlConnectionStringBuilder object, and pass in our “base” connection string PostgreSqlConnection from our appsettings.Development.json file.

       
   2. b.

      Continue to “build” the string by passing in both our UserID and Password secret from our secrets.json file.

       
    
3. 3.

   Replace the original connection string with the newly constructed string using our builder object.

    

Save your work, build it, then run it. Fire up Postman, and issue our GET request to our API. You should get a success!

Celebration Checkpoint

You have now dynamically created a connection string using a combination of configuration sources, one of which is User Secrets from our secrets.json file!

Just cast your mind back to the following diagram.

The .NET Configuration layer by default provides us access to the configuration sources as shown in Figure 8-18; in this case we used a combination of 2 + 3.