Would it not be better to store connection string in appsettings.json to utilise the built in config transforming provided by IConfigurationBuilder and allow easy setup for multiple environments e.g. appsettings.QA.json, appsettings.UAT.json?
Alternatively perhaps DataSettingsManager -> DataSettingsFilePath could pulled out of appsettings.json so the datasettings.json could be swapped per environment.
we've thought about it. But as long as we know asp.net doesn't support editing (saving) of appsettings.json now
OK so installer has an impact gotya, how about the latter idea of pulling datasettings path from config file so the path could be switched per ENV?
Only loading dataSettings.json as a fallback when not defined through the .NET Core settings loader would mean I could throw out some of my custom code to do this - has my vote 馃憤
Further to the original point on using appsettings and the response that it's not possible to persist, dot net core team seem happy to suggest creating your own provider which will persist, it's not discouraged to do so.
Name-value pairs written to the built-in Configuration providers are not persisted. However, a custom
provider that saves values can be created. See custom configuration provider.
after soem consideration we've decided to leave the current implementation
Care to share your reasoning? I'm happy to implement the change if it's just low priority?
the way settings are done makes it hard to do ci/cd and password rotation.
Most helpful comment
Care to share your reasoning? I'm happy to implement the change if it's just low priority?