Hey all. When we first imagined these Key/Value config builders and how they could be useful for securing secrets or assisting lift and shift into container environments, the obvious targets for injecting config values were the two most prominent key/value config sections. AppSettings and ConnectionStrings. The configuration builders feature in the framework is not restricted to those two sections though. When considering improvements to be made in vNext of these Key/Value-centric config builders, I wondered if anyone wants to use these on config sections other than the two mentioned above. So... some questions:
- Would you want to be able to apply values from a key/value source to a config section other than the two that are already handled? If so, which sections? And is 'Expand' mode sufficient for your needs, or are 'Strict' or 'Greedy' preferrable in some cases?
- If the key/value base code were changed to operate on any config section using an enumerable-ish config section handler*, what would be the preferred way to find these handlers for other sections? (Keep in mind, the config system is initialized and some sections are loaded before any 'startup' code gets to run.) Reflection magic? Application of a 'dummy' builder to the config section that registers the handler for that section for builders later in the list?
*-A handler could expose the config section it handles as an enumeration of key/config-unit pairs, and also contain a Insert/ReplaceValue(config-unit, key, value) method that knows how to insert the looked-up config value for the given key into the config-unit returned by its own enumeration.
Hey all. When we first imagined these Key/Value config builders and how they could be useful for securing secrets or assisting lift and shift into container environments, the obvious targets for injecting config values were the two most prominent key/value config sections. AppSettings and ConnectionStrings. The configuration builders feature in the framework is not restricted to those two sections though. When considering improvements to be made in vNext of these Key/Value-centric config builders, I wondered if anyone wants to use these on config sections other than the two mentioned above. So... some questions:
*-A handler could expose the config section it handles as an enumeration of key/config-unit pairs, and also contain a Insert/ReplaceValue(config-unit, key, value) method that knows how to insert the looked-up config value for the given key into the config-unit returned by its own enumeration.