Variable Substitution strategy

Legacy Uncategorised
1

How can I keep a set of working configuration files (primarily xmlfiles) in my repository and still be able to perform variable substitution (with iteration) on these files? Previously I’ve done this using xml transformations together with variable substitution which works, but it quite tideous if I have many files. For xml files, this workds, but what about other files? Eg “.json configuration files”. There are no transformations available for such files. I do not want to have “{#}”-statements in my checked in files because that would mean that the project would not work straight from the repository which is a must for all the developers that are supposed to be able to degub the project on their local machine.

2

Hi Emil,

Thanks for getting in touch! The state of the world of ASP.NET Core is changing quickly but at this point you can provide multiple .json configuration files by loading them in your application:

var builder = new ConfigurationBuilder()  
                .AddJsonFile("appsettings.json")
                .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true);

In this example your app will load appsettings.json and override with matching values from appsettings.{env.EnvironmentName}.json if the file exists.

This means you can use appsettings.json for your development environment, and then create either:

a) One file per environment (like config transforms) so you can source-control your configuration
b) A single file (like appsettings.Environment.json) filled with #{MyVariable} binding expressions so you can use Octopus to control your configuration. In this case you would use something like .AddJsonFile("appsettings.Environment.json")

Having not done this in anger myself yet, hopefully this gets you most of the way to a working solution.

Please keep me in the loop and I will update our documentation to be more informative.

Hope that helps!
Mike

3

Thanks for the reply. For ASP.NET Core, this certainly looks like a nice solution. The thing is that in this particular project I have some non ASP.NET Core json configuration files kind of “custom designed” so I am not sure I can use the technique described above for this particular project.

4

Hi Emil,

Thanks for getting back to me. In that case, I would build something similar into your application, but instead of an “override” behaviour, you could implement a simple “find the right file for this environment” behaviour.

  • In Development: use an environment variable, or #if DEBUG to select the dev file with fixed values
  • In Deployed Environments: #ELSE to select the App.Octopus.json file perhaps - and this is the one with the bindings

At this point we aren’t planning to build anything Octopus-specific that does a “config transform” equivalent for JSON config files, since our main target for this is the .NET Core Configuration tooling/framework, which eventually we think people will use for ASP.NET and other applications on .NET Core.

Hope that helps!
Mike

5

Thanks for the response, great idea.