Skip to content

Configuration

Configuration system

Bizzkit Blueprint uses standard ASP.NET Core application configuration.

To make configuration files more manageable we tend to have one per project that needs configuation instead of one giant file for the solution.

That means if you need to change a config file for something PIM related you navigate to the Bizzkit PIM integration project and find the config file there.

{{% alert title="Note" color="primary" %}} Both configuration and dependency injection is setup in each project with extension methods. Look for a file called "*ServiceCollectionExtensions.cs" in each project. {{% /alert %}}

Priority

We load configuration values in the following order:

  1. Base configuration files.
  2. Environment specific configuration files.
  3. Environment variables.

For any specific configuration key the last value loaded wins.

Configuration files

The configuration system is setup to first load all files matching the following pattern: "appsettings.Blueprint.*.json". There are a number of these files - one for each project that uses configuration.

Next it loads all files matching the following pattern: $"appsettings.{env}.Blueprint.*.json" where env is the environment name. We typically have the following different environment names: Development, QA, Test and Production.

So you keep the basic stuff in the base file and then you override what you need in the environment specific file.

{{% alert title="Warning" color="warning" %}} Do not store sensitive configuration values in the config files you commit to your repository. Use environment variables or another config provider like Azure Key Vault for these and leave the values empty in the config files. It is also possible to insert the values in a secure way during deployment if you use something like Octopus Deploy for this. {{% /alert %}}

Environment variables

Environment variables are loaded using the standard configuration provider for this.

In addition to this we have tweaked the system a bit. We added support for .env files. So if you leave one of these in the root folder of one of the application entry points (website, jobserver etc.) these environment values also get loaded. They get loaded at application startup so they override what is set already by the system.

Note, that .env files are set to be ignored by Git in the .gitignore-file, so you don't commit these by accident.