Can you preview ASP.NET Core's appsettings.json environment overrides?

Question

In ASP.NET Core, the JsonConfigurationProvider will load configuration from appsettings.json, and then will read in the environment version, appsettings.{Environment}.json, based on what IHostingEnvironment.EnvironmentName is. The environment version can override the values of the base appsettings.json.

Is there any reasonable way to preview what the resulting overridden configuration looks like?

Obviously, you could write unit tests that explicitly test that elements are overridden to your expectations, but that would be a very laborious workaround with upkeep for every time you change a setting. It's not a good solution if you just wanted to validate that you didn't misplace a bracket or misspell an element name.

Back in ASP.NET's web.config transforms, you could simply right-click on a transform in Visual Studio and choose "Preview Transform". There are also many other ways to preview an XSLT transform outside of Visual Studio. Even for web.config parameterization with Parameters.xml, you could at least execute Web Deploy and review the resulting web.config to make sure it came out right.

There does not seem to be any built-in way to preview appsettings.{Environment}.json's effects on the base file in Visual Studio. I haven't been able to find anything outside of VS to help with this either. JSON overriding doesn't appear to be all that commonplace, even though it is now an integral part of ASP.NET Core.

Answer 1

I've figured out you can achieve a preview with Json.NET's Merge function after loading the appsettings files into JObjects.

Here's a simple console app demonstrating this. Provide it the path to where your appsettings files are and it will emit previews of how they'll look in each environment.

    static void Main(string[] args)
    {
        string targetPath = @"C:\path\to\my\app";

        // Parse appsettings.json
        var baseConfig = ParseAppSettings($@"{targetPath}\appsettings.json");

        // Find all appsettings.{env}.json's
        var regex = new Regex(@"appsettings\..+\.json");
        var environmentConfigs = Directory.GetFiles(targetPath, "*.json")
            .Where(path => regex.IsMatch(path));

        foreach (var env in environmentConfigs)
        {
            // Parse appsettings.{env}.json
            var transform = ParseAppSettings(env);

            // Clone baseConfig since Merge is a void operation
            var result = (JObject)baseConfig.DeepClone();

            // Merge the two, making sure to overwrite arrays
            result.Merge(transform, new JsonMergeSettings
            {
                MergeArrayHandling = MergeArrayHandling.Replace
            });

            // Write the preview to file
            string dest = $@"{targetPath}\preview-{Path.GetFileName(env)}";
            File.WriteAllText(dest, result.ToString());
        }
    }

    private static JObject ParseAppSettings(string path)
        => JObject.Load(new JsonTextReader(new StreamReader(path)));

While this is no guarantee there won't be some other config source won't override these once deployed, this will at least let you validate that the interactions between these two files will be handled correctly.

Answer 2

There's not really a way to do that, but I think a bit about how this actually works would help you understand why.

With config transforms, there was literal file modification, so it's easy enough to "preview" that, showing the resulting file. The config system in ASP.NET Core is completely different.

It's basically just a dictionary. During startup, each registered configuration provider is run in the order it was registered. The provider reads its configuration source, whether that be a JSON file, system environment variables, command line arguments, etc. and builds key-value pairs, which are then added to the main configuration "dictionary". An "override", such as appsettings.{environment}.json, is really just another JSON provider registered after the appsettings.json provider, which obviously uses a different source (JSON file). Since it's registered after, when an existing key is encountered, its value is overwritten, as is typical for anything being added to a dictionary.

In other words, the "preview" would be completed configuration object (dictionary), which is composed of a number of different sources, not just these JSON files, and things like environment variables or command line arguments will override even the environment-specific JSON (since they're registered after that), so you still wouldn't technically know the the environment-specific JSON applied or not, because the value could be coming from another source that overrode that.