Not Considering

CIL has been deprecated therefore no improvements for it will be provided anymore. Please consider alternatives in the later versions of the product. 

Allow usage of Environment Variables in web.config (or app.config) for CIL settings

The (.NET) CIL reads the connection settings for the discovery service from an app.config or web.config. Typically this will consist of:

  • discovery-service-uri
  • oauth-enabled
  • oauth-client-id
  • oauth-client-secret

It would be great if we could use environment variables for these values (as shown here: http://stackoverflow.com/a/29416404/866454) instead of having to enter this information in the config files.

Nuno Linhares

  •  Is it possible that a config has an explicit value set (which isn't a variable like ${variable_name}) but you'd still have an environment variable (even if you shouldn't)?

    I'm not familiar with the entire setup. I know they end up in the machine, but where do the environment variables come from themselves? In another file? What I'm wondering is how easy is it to set a config, default, or environment variable and be confused why the container isn't working. :-)

  •  - not 100% sure I follow you. If the value is present, and it's not a variable (i.e, not using some notation like ${variable_name} or %variable_name% as in the example I link to) then it should be taken literally. If it does use the chosen notation %var% or ${var} then it should be evaluated.

  • In our services configuration, we have support for environment variables, together with default values if such variables are not defined. Perhaps something similar could be used in our .NET CIL configuration? This library looks like it might be of help: github.com/.../Expansive

  • Working with environment variables instead of configuration seems to be the container-friendly way forward. But what are the expectations when you have both (say legacy) config files and want to use environment variables in the creation of a container, instance, or whatever? Does one take precedence over the other? Or should configs always have placeholders for the values you want to come from the environment?

  • We have this on our UDP backlog for prioritisation.