Configuration Management in ASP.NET 5.0 APIs

4 min readJun 25, 2021

Context

Configuration management is essential for every application that will be deployed into multiple environments, which is pretty much the majority of Apps and APIs. Focusing on APIs in this note, we will cover how to store configurations in your APIs, how to configure them, and finally how to read them.

By the way, this topic belongs to the series to set up an Asp.NET API for production use.

Configurations vs Secrets

Configurations are different from secrets. Secrets are values that should be protected and never be stored as plain text sitting in your repositories along with the rest of your code. The focus of this note is merely configuration management, and not secrets. You can refer to Secret Management for Asp.NET 5.0 Web APIs.

Reading

Starting from the end, you would like to have a convenient way to access your configurations from your code. Ideally you should have intellisense when accessing your configuration (and not using string literals as keys), and hence you will need to define a class that would be filled with all your configurations when your methods are run.

As you can see, this class will give you a nice structure on how to access your API configurations. Next, you will need to define your configuration key/values somewhere, and then at start up time, fill this class with all those values, and access it within your class.

Hence looking at how you use this class, ideally you’d like to inject an instance of this class anywhere you would need to access your configurations. We will be using IOptions as an injectable carrier of configurations.

Now anywhere in your SampleController class, you can access a well defined configuration structure.

Note
Configuration, plumbing and troubleshooting your software foundation take a considerable amount of time in your product development. Consider using Pellerex which is a complete foundation for your enterprise software products, providing source-included Identity and Payment functions across UI (React), API (.NET), Pipeline (Azure DevOps) and Infrastructure (Kubernetes).

Storing

Following .Net 5.0 practices, you can define your API configurations in an appsettings.json file at the root of your project. If you have different environments such as development, staging, and production, you will have a separate file for each environment, to override values which are different from the base file (appsettings.json) which we allocate to values for development. If any value is the same across all environments, it won’t need to be repeated for the prod file for example (appsettings.production.json).

According to what we have in our AppSettings class, the structure of the setting file should be like below, which creates a 1:1 mapping with your class properties:

Loading

Now what’s left is to load the config values from appsettings.json file at startup time, and now write them to an instance of AppSettings class, and inject it within our dependency injection space. In our startup.cs file, we define a method to do just that:

This code is self-explanatory, it basically reads the environment variable (“ASPNETCORE_ENVIRONMENT”), which tells which environment the code is running in. On your development machine, this will be ‘Development’, and when you deploy your code to production, you need to make sure the variable is set to Production if you’d like this method to read the appsettings.production.json values for production environment.

ASPNETCORE_ENVIRONMENT Needs to Exist in All Environments

If you are deploying your code into Azure Web Apps, make sure you define this environment variables as part of your app settings, otherwise your production config values won’t be loaded. It’s best if you could automate this step, so whenever you deploy your app, even as a brand new API, this setting will be created with no need for a manual step.

Access Config Values in Start Up File

At the end of SetupConfiguration method, what you get is an object which has all the configuration values, has been already injected into your dependency injection ecosystem, and can be used to even access config values in your start up file.

Pellerex Foundation: For Your Next Enterprise Software

How are you building your current software today? Build everything from scratch or use a foundation to save on development time, budget and resources? For an enterprise software MVP, which might take 8–12 months with a small team, you might indeed spend 6 months on your foundation. Things like Identity, Payment, Infrastructure, DevOps, etc. they all take time, while contributing not much to your actual product. These features are needed, but they are not your differentiators.

Pellerex does just that. It provides a foundation that save you a lot development time and effort at a fraction of the cost. It gives you source-included Identity, Payment, Infrastructure, and DevOps to build Web, Api and Mobile apps all-integrated and ready-to-go on day 1.

Check out Pellerex and talk to our team today to start building your next enterprise software fast.