Steve Collins Profile Picture Steve Collins

Let's face it, we've all done it at some point. You have a value in your code that you don't want to hard code as it will vary in different environments or needs to change in a runtime environment, so you want to make it configurable in a file. That's where the fun begins.

In the .NET Framework, you usually create an XML configuration file and reference it using some static methods. Or maybe you use the designer in Visual Studio to do the work for you? In .NET Core, you are given a JSON file by default and access it through the IConfiguration interface. Job done ...or so you think.

·     How do you code the keys to access the values?
·     How do you unit test it and what if you need to test different values?
·     What if you want to store values other than primitive types?
·     What if you want to have secure passwords, but don't want them in your source control?
·     What if you don't want to use json files ... or come to that, don't want to use files at all?
·     What if you want to change values in a Docker container

.. and the questions go on and on.

In this talk, we start with a brief overview of the history of configuration in .NET Framework and how Microsoft handed developers a loaded gun to shoot themselves in the foot. Moving on to .NET Core, things are much better, but there are still some gotchas.

Lastly, the talk goes on to deal with the questions raised above with a "SOLID" based approach that makes configuration not only fully testable, but adds enhancements to handle encrypted configuration values (because you're not storing passwords as clear text in source control are you?) and validation of the configuration data before it hits your code.

The talk aims to help new developers avoid the pitfalls that others have fallen down and give experienced developers some food for thought as to how they might want to reconsider how they do configuration.