You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@slonopotamussuggested in another issue that setting the DSN in an environment variable should override an empty string (i.e. disabled) value that has been set via other bindings (like appsettings.json).
Using the default configuration, the EnvironmentVariablesConfigurationProvider loads configuration from environment variable key-value pairs after reading appsettings.json, appsettings.{Environment}.json, and user secrets. Therefore, key values read from the environment override values read from appsettings.json, appsettings.{Environment}.json, and user secrets.
I think if we do this, it shouldn't be just for the DSN and shouldn't be just for the disabled DSN value... but that env variables trump other provider sources more generally.
However this is likely a breaking changes as we may have many customers who have their production environments configured based on the current behaviour.
The text was updated successfully, but these errors were encountered:
@slonopotamus suggested in another issue that setting the DSN in an environment variable should override an empty string (i.e. disabled) value that has been set via other bindings (like appsettings.json).
This would be more consistent with how things are done in ASP.NET Core:
I think if we do this, it shouldn't be just for the DSN and shouldn't be just for the disabled DSN value... but that env variables trump other provider sources more generally.
However this is likely a breaking changes as we may have many customers who have their production environments configured based on the current behaviour.
The text was updated successfully, but these errors were encountered: