Who

The following are some of the tools that leverage .netconfig to provide flexible configuration persistence options:

Learn more about how the various tools leverage .netconfig in the Who section of our docs site.

How

Format

Example file:

The syntax follows closely the git-config syntax. The # and ; characters begin comments to the end of line, blank lines are ignored.

The file consists of sections and variables. A section begins with the name of the section in square brackets and continues until the next section begins. Section names are case-insensitive. Only alphanumeric characters and - are allowed in section names. Each variable must belong to some section, which means that there must be a section header before the first setting of a variable.

Sections can be further divided into subsections. To begin a subsection put its name in double quotes, separated by space from the section name, in the section header, like in the example below:

Subsection names are case sensitive and can contain any characters except newline. Doublequote " and backslash \ can be included by escaping them as \" and \\, respectively.

Section headers cannot span multiple lines. Variables may belong directly to a section or to a given subsection. You can have [section] if you have [section "subsection"], but you don't need to.

All the other lines are recognized as setting variables, in the form name = value (or just name, which is a short-hand to say that the variable is the boolean true). Variable names are case-insensitive, allow only alphanumeric characters and -, and must start with an alphabetic character. Variables may appear multiple times; we say then that the variable is multivalued.

Leading whitespaces after name =, the remainder of the line after the first comment character # or ;, and trailing whitespaces of the line are discarded unless they are enclosed in double quotes. Internal whitespaces within the value are retained verbatim.

Backslash \ characters must always be escaped with \\. Double quotes must either be escaped with \" or be properly balanced, which causes the whitespace within to be preserved verbatim.

Beside \" and \\, only \n for newline character (NL) and \t for horizontal tabulation (HT, TAB) escape sequences are recognized.

NOTE: when using the CLI or API, these escaping rules are applied automatically

Values

Values of many variables are treated as a simple string, but there are variables that take values of specific types and there are rules as to how to spell them.

• boolean

  When a variable is said to take a boolean value, many synonyms are accepted for true and false; these are all case-insensitive.

  • true: boolean true literals are yes, on, true, and 1. Also, a variable defined without =<value> is taken as true.

  • false: boolean false literals are no, off, false, 0 and the empty string.

• datetime

  Variables of this type are always parsed/written using ISO 8601 (or round-trip) format.

• number

  The value for many variables that specify various sizes can be suffixed with k, M, G or T to mean "scale the number by 1024", "by 1024x1024", "by 1024x1024x1024" or "by 1024x1024x1024x1024" respectively. The suffix is case insensitive, and can also include the b, as in kb or MB.

Array of complex objects

Creation of more complex objects in array is possible via subsections. Lets say that we have following configuration object:

We would like to retrieve from our configuration as IList<WatchedProcess>. Even if git-config syntax does not have direct support for this scenario, we are able to create list of complex object with subsection and ConfigurationRoot.

ConfigurationRoot supports working with arrays by creating indices for items as "subsections". This allows us to create a section selector that picks values from the array based on the element index. For example, WatchedProcess:0:Name selects the value Name from the first item in the array. This means we can use indices as subsections and create an array of complex objects as follows:

With this configuration we are able to retrieve array of complex objects in following way:

NOTE: be sure that your array items have unique index

API

There are three main ways to access .netconfig values:

• Native API for direct access to .netconfig values
• Microsoft.Extensions.Configuration provider
• System.CommandLine for CLI apps

Native API

The main usage for .NET tool authors consuming the DotNetConfig API is to first build a configuration from a specific path (will assume current directory if omitted):

The resulting configuration will contain the hierarchical variables set in the current directory (or the given path), all its ancestor directories, plus global and system locations.

When getting values, the supported primitives are exposed as first-class methods for Add, Get and Set, so you get quite a few usability overloads for each of Boolean, DateTime, Number and String, such as AddBoolean, GetDateTime, GetString or SetNumber:

Alternatively you can use the TryGetXXX methods instead, to avoid checking for null return values in cases where the variable (in the requested section and optional subsection) is not found:

Since .netconfig supports multi-valued variables, you can retrieve all entries as ConfigEntry and inspect or manipulate them granularly:

When writing values (via AddXXX or SetXXX) you can optionally specify the configuration level to use for persisting the value, by passing a ConfigLevel:

IMPORTANT: the Config API is immutable, so if you make changes, you should update your reference to the newly updated Config, otherwise, subsequent changes would override prior ones.

You can explore the entire API in the docs site.

Microsoft.Extensions.Configuration

Usage (in this example, also chaining other providers):

Given the following .netconfig:

You can read both values with:

System.CommandLine

Given the explicit goal of making .netconfig a first-class citizen among dotnet (global) tools, it offers excelent and seamless integration with System.CommandLine.

Let's asume you create a CLI app named package which manages your local cache of packages (i.e. NuGet). You might have a couple commands, like download and prune, like so:

The added WithConfigurableDefaults invocation means that now all arguments and options can have their default values specified in config, such as:

Note how the id can be specified at the top level too. The integration will automatically promote configurable values to ancestor sections as long as they have compatible types (both id in download and prune commands are defined as string).

Running package -? from the command line will now pull the rendered default values from config, so you can see what will actually be used if the command is run with no values:

And package prune -? would show:

Since .netconfig supports multi-valued variables, it's great for populating default values for arguments or options that can be specified more than once. By making this simple change to the argument above:

We can now support a configuration like the following:

And running the command with no id argument will now cause the handler to receive all three. You can also verify that this is the case via download -?, for example:

All the types supported by System.CommandLine for multiple artity arguments and options are automatically populated: arrays, IEnumerable<T>, ICollection<T>, IList<T> and List<T>.

For numbers, the argument/option can be either long or int. Keep in mind that since numbers in .netconfig are always long, truncation may occur in the latter case.

CLI

The command line tool allows you to inspect and modify configuration files used by your dotnet tools. Installation is the same as for any other dotnet tool:

The available options and actions are (for the most part) compatible with the behavior of git config.

When reading and writing from a single file, you can for the most part just use git config along with the compatibility option -f|--file specifying the file to read/write from.

Reading and writing variables don't require any special options. The following lines first write a variable value and then retrieve its value:

The value is returned verbatim via the standard output, so you can assign it directly to a variable, for example.

All current options from running dotnet config -? are:

Command line parsing is done with Mono.Options so all the following variants for arguments are supported: -flag, --flag, /flag, -flag=value, --flag=value, /flag=value, -flag:value, --flag:value, /flag:value, -flag value, --flag value, /flag value.

Sponsors

Learn more about GitHub Sponsors