Support Environment Variables

[ChrisMissal]

Formo should support environment variables. Rather than start coding, I'm using this as place for notes, thoughts, and ideas from others. I don't want to end up painting developers into a corner should they decide to use it.

Things to consider:

• [ ] What should happen when a key exists in both config file and env variables? Throw exception, use config, force user to specify the strategy if using both, other?
• [ ] Should this be added to Configuration.cs or should a new class be created?
• [ ] Should there be strategies for duplicate keys having a preference on where to fetch the associated value?

[ChrisMissal]

Additional thoughts @drusellers?

[chaitanyagurrapu]

Perhaps this idea can be generalised further to introduce the concept of a pluggable "Configuration Source"? Environment variables can be one type of source and config files can be another type. And for every configuration value it needs to look up, it can iterate through an ordered list of sources. There can also be other types of sources such as a Teamcity/Hudson/Jenkins etc., Octopus deploy or a database.

For example, in my current project, a lot of configuration is saved as Teamcity configuration parameters. Things such as database server names, service account names and passwords (production parameters obviously shouldn't be stored in config files accessible to developers). As well as which test environments use stubs for external systems vs which one use a real test versions of the external systems. And at deploy time, Teamcity does a combination of text replace on config files and/or config transform files before running the config transforms. Otherwise, we were ending up with config transform files for each config file for each environment we were deploying to and a lot of the values were network/deployment concerns, not application concerns.

It would be much neater if we had a web.config file which had all the default values required for local development by the developers (i.e, the Configuration Source would just be set to 'File'). And just one release config transform file which changed the "Configuration Source" from "File" to "Teamcity,File" for example). This way when a new developer joins the team, they can just get the code and start working without worrying about configuring the application, and when we change any of the deployment parameters or add new environments, we don't have to create/update a whole heap of config transform files. We just update or create the values in whatever we have picked as the "Configuration Source" and start using it.

[drusellers]

+1 for a source model

What should happen when a key exists in both config file and env variables? Throw exception, use config, force user to specify the strategy if using both, other?

I would suggest having a precedence order so that its clear which key would win.

Should this be added to Configuration.cs or should a new class be created?

No opinion. :(

Should there be strategies for duplicate keys having a preference on where to fetch the associated value?

Yes

---

In magnum we have a Configuration Source per source. The configuration source is able to convert a key request into a value. When there are multiple configuration sources, we simply enumerate them looking for a match in each one.

Magnum Configuration

_binder = ConfigurationBinderFactory.New(x =>
{
    // least specific to most specific
    x.AddJson(jsonStream);
    x.AddCommandLine(commandLineText);
});

[ChrisMissal]

Closing this issue since these concerns will be addressed in the near future: https://github.com/aspnet/Configuration