[API Proposal]: Allow to save configurations in IConfiguration

[msedi]

Background and motivation

This proposal is about to enable saving and manipulating configurations in Microsoft.Extensions.Configuration.*.

This request has been brought up many times in https://github.com/dotnet/AspNetApiDocs/issues/89, aspnet/Configuration#385 and others, but has been discussed away by stating that it was intended to be immutable for many reasons that have to do with ASP.NET.

While all the arguments might partially be true for ASP.NET for deployments reasons, etc. this statement is wrong for desktop applications. Here you have dialogs or other options where you change settings in your UI. Sometimes you event have to, for example if you want to remember if the application has started for the first time, or other user settings that you have to persist. I think all of us agree that there are countless things that need to be stored.

There is also System.Configuration which has the ability to save, but there is not chance to configure where you want to load it.

In the end, the proposal is all about adding a possibility to simply store the configuration.

API Proposal

Instead of having a IConfigurationSource we need an IConfigurationSink that has the inverse behavior of IConfigurationSource

The IConfiguration gets a new method for persisting configuration:

IConfiguration.Save(IConfigurationSink sink)

API Usage

var config = ConfigurationBuilder().AddIniFIle("c:\test.ini").Build(); config["test"] = "ok";

config.Save(new JsonConfigurationSink("D:\\test.user.ini"));

Alternative Designs

Surely there a many things to discuss, so please just see this as a starter.

Risks

The problem currently is that there are many providers from different sources. So the question is if it should be saved back to the individual providers, or if there is a single configuration file.

If you ask me I would go with a single configuration file that can be saved with a single provider this provider can be added additionally to the configuration which would cause loading the configuration from many sources using different providers. As a last step all current data is overwritten by the last provider (which could als made a bit more explicit so that it can easily be seen from the builder what is an overriding configuration).

[ghost]

Tagging subscribers to this area: @dotnet/area-extensions-configuration
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and motivation

This proposal is about to enable saving and manipulating configurations in Microsoft.Extensions.Configuration.*.

This request has been brought up many times in https://github.com/dotnet/AspNetApiDocs/issues/89, aspnet/Configuration#385 and others, but has been discussed away by stating that it was intended to be immutable for many reasons that have to do with ASP.NET.

While all the arguments might partially be true for ASP.NET for deployments reasons, etc. this statement is wrong for desktop applications. Here you have dialogs or other options where you change settings in your UI. Sometimes you event have to, for example if you want to remember if the application has started for the first time, or other user settings that you have to persist. I think all of us agree that there are countless things that need to be stored.

There is also System.Configuration which has the ability to save, but there is not chance to configure where you want to load it.

In the end, the proposal is all about adding a possibility to simply store the configuration.

API Proposal

Instead of having a IConfigurationSource we need an IConfigurationSink that has the inverse behavior of IConfigurationSource

The IConfiguration gets a new method for persisting configuration:

IConfiguration.Save(IConfigurationSink sink)

API Usage

var config = ConfigurationBuilder().AddIniFIle("c:\test.ini").Build(); config["test"] = "ok";

config.Save(new JsonConfigurationSink("D:\test.user.ini"));

Alternative Designs

Surely there a many things to discuss, so please just see this as a starter.

Risks

The problem currently is that there are many providers from different sources. So the question is if it should be saved back to the individual providers, or if there is a single configuration file.

If you ask me I would go with a single configuration file that can be saved with a single provider this provider can be added additionally to the configuration which would cause loading the configuration from many sources using different providers. As a last step all current data is overwritten by the last provider (which could als made a bit more explicit so that it can easily be seen from the builder what is an overriding configuration).

Author:	msedi
Assignees:	-
Labels:	api-suggestion, untriaged, area-Extensions-Configuration
Milestone:	-

[ahdung]

Any news?

[eerhardt]

@ahdung - we don't have any plans on addressing this in the near future.

If you need to persist preference/config data in your application, my suggestion is to do it some other way than through IConfiguration. Your app can write to your appsettings.json file (or whatever config location you chose) through normal I/O APIs. Then you can reload your config using the new file contents.

[msedi]

@eerhardt: I assuming mostly every desktop application needs to read and write configuration settings. Currently both solution that are presented by .NET do not fully support common scenarios. System.Configuration does not allow to load the config from a user-defined place, Microsoft.Extensions.Configuration do not allow to be saved.

I would really be good to have one solution that fits common use cases. In the current state I can use neither nor of both solutions which is a bit sad since only for this "little" feature they cannot be used in widespread scenarios.

[eerhardt]

Can you explain why writing to the file directly doesn't work for you?

[DPetersen257]

@msedi
An example provided to me a week ago on the C# discord that has worked pretty well:

https://pastie.io/pqertx.cs
Then just register it in dependency injection with
builder.Services.AddSingleton(OgmaConfig.Init("MyConfig.json"))

You then have the ability to bind it to an object and save as desired

[msedi]

Can you explain why writing to the file directly doesn't work for you?

I'm not exactly sure what you mean. Do you mean simply saving the configuration via a Json file writer? I could save each configuration to a separate file, thats true but my own solution (not using one of the two *.Configuration classes) has a structured subfolders like a filesystem, so I can bind any hierachical object in substructure.

As you see, I already have a working solution but I wanted to go with some more maintained and more features 3rd party class. Its not that I personally urgently need it. Its just something more people for sure need ;-)

[ahdung]

@eerhardt As a configuration solution, just can only read, can't store, then it is a disabled solution, isn't it?

[davidfowl]

Yes, it is, but it was designed to be mostly read only. There are lots of strange behaviors to work out when persisting back to the configuration provider is allowed (order, multiple, etc etc). While I don't want to downplay the use cases, they pale in comparison to the reading cases, so this work isn't going to be prioritized over other configuration work.

PS: This API proposal should really come after a full implementation spike has been done and lots of hard questions answered. The team does not see the value so will not be doing that work, but this API proposal is premature.

I would expect something like this #43359 (comment), for a feature of this magnitude.

[ohsorry]

it is .NET9 now! you have Load and a bunch of help method but no Save, what's that design??