AppSettings Studio

A graphical interface for centralized management of .NET appsettings.json files. It offers a unified view to edit, validate, and apply configuration changes across multiple projects or executables—including WSL on Windows—with support for live updates.

AppSettings Studio builds on Microsoft.Extensions.Logging.Configuration and specifically leverages the JSON provider.

Although primarily designed for .NET developers during development and testing, there’s nothing preventing its use in production. It supports all types of .NET applications—Web, Console, etc.—running on both Windows and Linux.

Possible use cases:

• Centralized management of appsettings.json files
• Enable per-developper app settings configuration
• Avoid storing per-developer appsettings.json files in source control repository
• Avoid storing secrets in source control repository (appsettings.json files can just contain comments and placeholders)
• Simplify settings management for the same application deployed or used differently (debug vs release, v1 vs v2, WSL vs Windows, git submodules, multiple repo clones, etc.)
• Easy support for dynamic settings changes
• Easy settings change with a syntax coloring enabled Json editor
• etc.

Note this tool's objective is not to share common appsettings.json between developpers. For that, there's already source control. It's quite the opposite: allow every developer to centralize and manage all personal custom settings and secrets for all applications they're working on, independently from other developers, and without doing any modification of common "official" appsettings possibly put in source control.

The solution consists of two main components:

1. AppSettingsStudio.Configuration assembly – a standard .NET Configuration Provider. This must be included in any application that should integrate with the AppSettings Studio application.

2. AppSettings Studio application (WinForms) – a desktop tool that enables developers to configure all registered applications. Note it requires Microsoft's WebView2 to be installed.

The solution also contains a Sample.ConsoleApp console application that demonstrate how it works.

Enabling an application

To be able to use AppSettings Studio, an application must be "enabled". For that, all is needed is to inject AppSettings Studio's ConfigurationProvider service into the application using standard .NET dependency injection, something like that:

// add a reference to AppSettingsStudio.Configuration.dll
...
using var host = Host.CreateDefaultBuilder(args)
...
.ConfigureAppConfiguration((context, config) =>
{
    config
    // add AppSettingsStudio configuration provider (singleton) somewhere around here
    .AddAppSettingsStudio(config =>
    {
        // define AppSettingsStudio options
        config.Options |= SettingsOptions.GatherAppSettingsFile | SettingsOptions.MonitorChanges;
    });
})
.Build();
...

GatherAppSettingsFile tells the system to gather an appsettings.json file in AppSettings Studio. This gathering step needs to be performed at least once but can be skipped afterward. By default, if no option is provided, it only runs in DEBUG builds—preventing accidental execution in production.

MonitorChanges tells the system to reload the settings each time it's changed in AppSettings Studio.

Configuring an application with "virtual settings"

The first time the application is ran, and if it was configured to gather it's appsettings.json file, the application should appear in AppSettings Studio. For example, since AppSettings Studio is itself enabled, the first time you run it, this is what you should see:

AppSettings Studio automatically uses the application’s icon if available. For better readability—especially when managing multiple applications—it’s recommended to provide one. All .NET executables, including web applications, can have an icon assigned.

When you select an application's appsettings.json file in the left tree view, you can see on the right pane a json editor (powered by the Monaco Editor). For all originally gathered appsettings.json files from all enabled application, the editor is in read-only mode:

To be able to change an app's settings, you just need to create a "Virtual Settings", so right click on an appsettings.json node in the tree view, select "Add Virtual Settings...":

Choose a name (it must start with appsettings and be a .json file):

Now, this setting's json, with a content initialized from the gathered appsettings.json's content, is editable, and you can save the change (CTRL+S as a shortcut):

Note: since the editor is based on Monaco, you can use standard Monaco shortcuts, so for example ALT+SHIFT+F reformats the JSON, you can use the mouse wheel for zooming in & out, etc.

Now, when you restart the .NET application, it will use the new settings. If the application supports it, changes can also be reflected dynamically in real-time (see next chapter).

You can configure more than one settings per instance of an application, but only one is considered as active: the one that has the icon with a small green "O" overlay:

You can change the active settings by right clicking on a settings node and selecting "Make Active"

You can also import an existing settings, from a fellow developer for example, by right clicking on an application's instance node and selecting "Import Virtual Settings..."

Dynamic settings change

You can enable an application's settings to change at the same time you edit it AppSettings Studio. There are two requirements:

1. the application must follow .NET Configurations's IOptionsMonitor pattern
2. the application must be configured with the SettingsOptions.MonitorChanges option (see above)

The Sample.ConsoleApp project demonstrates this.

What this sample code does is continuously display the value of one of it's custom settings property:

...
// get a loggger from DI
var logger = host.Services.GetRequiredService<ILogger<Program>>();

// get the a dynamic (can be changed during exection) PositionOptions monitor from DI
var options = host.Services.GetRequiredService<IOptionsMonitor<PositionOptions>>();
while (true)
{
    logger.LogInformation("Hello {Name}", options.CurrentValue.Name);
    await Task.Delay(500);
}

public class PositionOptions
{
    public const string Position = "Position";

    public string Title { get; set; } = string.Empty;
    public string Name { get; set; } = string.Empty;
}    

Just run it and change the settings in AppSettings Studio at the same time. Each time you save, the application reflects it. Here changed the Position's Name to "Joe Smith Senior" and undo:

This is the same exact .NET app running in WSL Ubuntu (see following chapter on how to configure this):

Enabling an application running on WSL

AppSettings Studio has the concept of "root paths". They are configured directories which contain gathered appsettings.json files pointers, virtual ones as well as links.

By default, only one root path exists: %USERPROFILE%\.AppSettingsStudio, so for example C:\Users\<your login>\.AppSettingsStudio, but you can add others.

This can be used for a certain level of settings sharing among multiple developers, but this is also how you can configure .NET apps running in WSL.

Once you have started an enabled .NET application in WSL at least once, open AppSettings Studio and select the "File" / "Root Paths" menu

Select the .AppSettingsStudio directory that has been created in the WSL volume:

Two root paths are now configured:

Now, AppSettings Studio shows you .NET apps running in WSL and .NET apps running in Windows:

Note: all WSL apps appear under a "dotnet" tree item because they are all lauched by same "dotnet" executable.

Same application, multiple instances

The same .NET application can be deployed multiple times for different reasons : Debug vs Relese, Testing environment vs Developer environment, versioning, etc. An application is by default identified by the name of it's executable, not by the directory it exists in.

AppSettings Studio allows centralization of all these settings in one place, for example if the Sample.ConsoleApp is only run in Debug, this is what we'll see:

But once it's been also run in Release (so the Release appsettings.json file has been gathered), there are now two child nodes under the application node, prefixed by Debug and Release:

Note: AppSettings Studio automatically generates a unique, concise name for each application version to help distinguish them.

"Virtual Settings" links

To avoid copying settings for applications that can share them (like in the Debug vs Release case), you can create a "virtual settings" link to a "virtual settings".

You then can choose a source settings to link to:

Now, each time you change a source setting using the JSON editor, it will be reflected in all linked virtual settings:

Note: creating links between Windows and WSL is not supported.

Variables

AppSettings Studio supports two types of variables that you can use in virtual settings JSON properties values (not keys):

1. AppSettings Studio's Global variables. They can be declared using the @(name of variable) syntax.
2. Environment variables. They can be declared using the $(name of variable) syntax.

To declare an AppSettings Studio variable just select the "Edit", "Global Variables..." menu:

A Global Variable is a key + value pair, and you can use the key anywhere in a JSON property value (it can be in the middle of the property value):