Why there is no save in ConfigurationProvider?

[andrew-vdb]

https://github.com/aspnet/Configuration/blob/f4e4e530b0baeb6c939e6a63950acdd3d26be832/src/Microsoft.Extensions.Configuration/ConfigurationProvider.cs

Maybe duplicates,
It seems so obvious, why there is no save?

public virtual void Save()
        {
        }

Is the configuration only supporting read only setting?
What kind of setting that never change?

There is no AddSetting here
https://github.com/aspnet/Configuration/blob/81115be8b1f1a369c08372d8e7b45317d434fd65/src/Microsoft.Extensions.Configuration.Json/JsonConfigurationProvider.cs

[nbarbettini]

My understanding is that aspnet/Configuration is meant to always be read-only. It specifically ignores persistence concerns in an effort to be as lightweight as possible.

If you think about it, Configuration is basically replacing App.config - which was read-only as well. In my opinion, if you need to write configuration you need some sort of database.

The project folks can chime in if my understanding is incorrect here 😄

[herecydev]

@nbarbettini Sounds right to me, feels incorrect to write back to config. Some of the fundamentals of deployment tools like Octopus are based on that immutability of both the program and the configuration. If you allow the program to change the configuration you can run into all kinds of headaches as the behavior mutates with it.

[divega]

Yes, we want to keep Configuration lightweight and so we are conservative about adding features. Persistent is one of the features we have not rushed to implement in 1.0 but we could choose to implement in the future.

I think it is worth mentioning that Configuration is not immutable though. E.g. both the indexer property on IConfiguration and IConfigurationSection.Value are settable, calling GetSection() with an arbitrary configuration key will create a new IConfigurationSection that you can then populate, etc. It is only these changes are maintained in memory and there is currently no way to persist them back to the providers.

[nbarbettini]

Okay, so I guess I was half-correct.

I like what @herecydev pointed out. I'd be in favor of strict immutability, if that ever comes up.

[divega]

I have created an issue so that we can track persistence in the backlog: #386.

We have discussed immutability in the past but I think we had more compelling reasons to allow changes than to forbid them. One thing we considered that we just haven't designed yet is to have a version of the interface that does not include mutability (or perhaps an implementation that throws) that you could use to pass to components that you trust to read configuration but you don't trust with modifying the current configuration. I have created #387 in the backlog for that.

[andrew-vdb]

@nbarbettini AppConfig is writeable
http://stackoverflow.com/questions/11149556/app-config-change-value

@divega If I really want never changed settings, just use public const, why bother to use this config and option service?

//Super lightweight immutable read only setting and strong type!
public class AppSettings
{
public const int MajorVersion = "1";
}

What kind of Configuration that is not configurable? If you guys really want to have Read Only Configuration, then call it ReadOnlyConfiguration api

[herecydev]

It is configurable, just not from within the program itself. If you use global settings from within the code, every time you need to change them you need to ship a new version. That means a new version of your code for development, staging/production. etc.
We build code once and change the configuration depending on where it's going to live.

[andrew-vdb]

You are correct if its client app like winform or wpf but this is asp.net core, i put new code in a hot way while its running

[nbarbettini]

@andrew-vandenbrink The advantage to using Configuration over a simple POCO is that I can load my config from JSON, environment variables, command line, etc.

[jmatheti]

we wanted to give a handy tool to our deployment admin to run (dotnet xxx.dll), which allows them to input the sensitive data and in return gives protected string using DPAPI.

It will be nice to have a set/save configuration so that code can automate it, rather asking them to copy across to appsettings file.

every appsettings certainly have a sensitive data, which needs to be protected from third party people accessing the server. Something good to see persist/overwrite configuration feature. ( though we already have inmemory which is been used extensively for demo purpose - great little util)