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.

The point is not to share settings between developers, source control already does that. It is the opposite: each developer centralizes and manages their own personal settings and secrets for every app they work on, independently from everyone else, and without touching the official appsettings.json files kept in source control.

At a glance

• Centralize per-developer appsettings.json for all your .NET apps (Web, Desktop, etc.) without editing repo files.
• Manage multiple instances of the same app (Debug/Release, versions, WSL/Windows).
• Optional live updates when your app uses IOptionsMonitor.

How it works

1. Add the AppSettingsStudio.Configuration provider to your app.
2. Run the app once so its appsettings.json is gathered.
3. Use the desktop app to create a virtual settings file and make it active.
4. Restart the app (or use live updates) to apply changes.

Quick start

1. Follow the steps in Enabling an application.
2. Start your app once, then open AppSettings Studio to edit settings.
3. Create a virtual settings file and make it active.

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
• Get rid of appsettings.Development.json files (and all questions they rise)
• 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.

Comparing settings

You can compare the JSON content of any two settings files side by side. This is handy to see what differs between a Debug and a Release virtual settings, between a virtual settings and the original gathered appsettings.json, or between your settings and a colleague's imported ones.

There are two ways to open a comparison. Both reuse the last two comparable nodes you selected, so the two sides are usually already filled in for you:

• the "View", "Compare..." menu opens with the last two selected nodes as the left and right sides.
• right click a node that has a JSON editor. When another comparable node was selected just before, the menu reads "Compare to ''" and compares the two directly, otherwise it reads "Compare to..." and lets you pick the other side.

Either side can be chosen, or changed later, through the same tree browser used elsewhere in the app, so you are not limited to the two nodes you started from, and the "Swap sides" button flips the two. The toolbar offers a few options, all remembered between sessions:

• side by side or inline rendering.
• ignore trailing whitespace.
• word wrap.
• show whitespace.

The comparison window is modeless, so you can keep editing and saving your settings while it stays open. Click "Refresh" to re-read both files from disk. You can also turn on "Automatically Refresh On File Change" in the "File", "Preferences" menu, so the comparison updates on its own as soon as either file changes on disk. For example, edit a virtual settings in the editor, press CTRL+S, and the open comparison reflects the change right away.

The comparison uses the Monaco diff editor, so differences are highlighted just like in Visual Studio Code.

Files

Beside the applications, AppSettings Studio can keep a personal list of arbitrary files under a "Files" root node. This is handy to keep a few JSON files you often open or compare close at hand, without them being tied to any application.

Right click the "Files" node, or any folder under it, to organize your files:

• "Add Folder" creates a sub folder. Folders are just names to group files, they do not exist on disk, and you can nest them as deep as you want.
• "Add existing File..." adds one or more files. The picker is filtered to *.json by default, but you can pick any file.
• "Remove" (or the Delete key) takes a file or folder out of the tree. The file on disk is never touched.

Each file appears under its name on disk and opens in the same JSON editor as the rest, read only when the file itself is read only on disk. These files can also be chosen as either side of a comparison (see the previous chapter). The whole "Files" tree, with its folders and files, is saved with your settings and restored the next time you open the app, including which folders were expanded.

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):