This is just a short, sweet primer that details exactly how you can deal with Development and Production configuration files within the same project without the need to edit them upon deployment. It’s really a hugely over simplified example that allows those new to the subject to get a grasp of how his can be implemented in the real world.
In our situation we have a simple .NET core web application which has 2 databases , live and development… We could also include staging if you wanted to though we don’t in this example.
In this example our live database resides on a server called “MadeUpServer\SQL2035” whilst our development database resides on a server called “DEV-008\SQL2012”. So lets make a start. in the very first instance we need three things:-
- Main Configuration File – appsetttings.json
- Development Configuration File – appsettings.Development.json
- Production Configuration File – appsettings.Production.json
These are standard JSON configuration files and reside in the root directory of your .NET Core project thus:-
Visual Studio understands that there is a relationship defined by the naming convention of these files and thus automatically adds the .Dev and .Prod as child items of the main file. In reality they are stored at the same level within the project folder. The main appsettings folder will be populated with application settings that are shared across or act as the default for all configurations. They can of course be overridden at any level.
The Development JSON file will contain all of the settings peculiar to, or overridden by code run in the Development environment. The following screen grab shows both of these. We override the logging defaults and provide a connection string for the development database.
And finally the Production JSON file will house only those settings that pertain to the live production environment as you can see below. In this instance we have our crazy server name.
Just for the purposes of our code we are going to output the Server string onto our main page, so klets add a bit of code to the controller to deal with this. Firstly we ensure that we inject the configuration class that implements our IConfiguration interface into our main controller before storing the actual configuration string named ‘TrustedUser’ into a view bag so that the view can display the data.
Nice and simple, we then output the actual connection string within our Index Page using the data we stored in the ViewBag
And thats is from the point of view of the coding work. Now lets look at running it all up
Ok, So there are two sides of this equation. Firstly there is running these differing configurations in the development environment in Visual Studio, and then of course there is the main production deployment itself. Lets take a look at the former first.
Visual Studio has the concept of LaunchSettings which are stored in a rather aptly name file called LaunchSettings. Lets open our version up and define some run time configurations for visual studio to use.
We have basically drawn up four run time profiles here, the two profiles in green will assume we are running in a Production Environment (ASPNETCORE_ENVIRONMENT being the setting that controls this) and the two in red a Development environment. Don’t worry about the RepoMode, this is un related to this particular blog post at all. Upon adding and saving these profiles you should see that your “Run” button now contains all of the defined profiles.
Upon electing to run one of the Live (Production) profiles you should see that upon running up the main page we see the following configuration file being selected.
However, upon electing to run one of the Development profiles however you should see that a different configuration is picked up, like the following.
Ok, Thats nice and simple and is exactly the behaviour that we expected, How about in the deployment scenario? Well its fairly simple here although a little less obvious. We firstly set up our publish profile to the production (or staging) server. This we are not going to cover. However, we then need to make a small manual tweak to the Publish Profile XML file. Ensuring that ‘Show All Files’ is on at the top of our solution explorer we then select and open the profile that we just created.
Upon opening this file you should see a small snippet of XML contained within. We just need to make the following change to the XML adding the relevant EnvironmentName
Once done, we can publish to the server. If we take a look at the IIS server itself you should see the following under your configuration settings. As you can see the ASPNETCORE_ENVIRONMENT variable has been added and set as ‘Production’.
Dare we run it? Of course and as you should see the correct configuration will automatically be picked.
So no more worrying about resetting the configuration files during a deployment, no more copy pasting of the original files and no more live deployments pointing at …. test data. Just apply the separation at design time and… away you go.
None of this of course addresses the secrecy issues that arise from storing this kind of data within your configuration files. For that you need to head over to my Keeping Secrets Part 1 and Part 2 blog.