Show where each configuration key came from

[victorhurdugaci]

It would be nice if on the most verbose level you could get a log message when calling ConfigurationBuilder.Build showing you from where each loaded key comes from. Something like:

k1 (json:app.json)
- k2: v2(env var)
- k3: v3(json:app.json)
- k4: v4 (xml:app.xml)

[shirhatti]

This is not the first time we've received this feedback. We are considering taking this post 1.0

[husainaloos]

Currently, the configuration solution does not depend on any logger to log anything. Wouldn't introducing a logger be a breaking change?

[davidfowl]

You might introduce a cycle here, configuration can’t depend on logging so this would need to be done at another level entirely or not use the logging APIs

[MHHenriksen]

I'd like to point out an alternative solution, which we're using with good results in our projects:

Instead of logging the source location directly, attach it as metadata to each key-value-pair. It can be made available through separate methods to avoid breaking backwards compat, and makes it straightforward to log after logging has been initialized.

The info itself would be provided by the sources, giving them an opportunity to add more relevant details (from config.yaml line x, col y, referencing &id001), or use a completely different but more relevant syntax (default hard-coded value, from env var ASPNETCORE_URLS, autoconfigured during startup using dns hostname). The default config builder can transparently wrap old sources to at least attach the classname of the source.

An extra use case for this which I feel is the most important: Validation error feedback accuracy (you made this mistake in /path/to/config.json line x col y)