Configuration validation

[jakubfijalkowski]

We don't have any means to validate system-provided (e.g. env variables, KeyVault) configuration. Having such mechanisms would be beneficial, esp. for first time prod deployments (or when the config changes).

[marcin-dardzinski]

Any idea how could we address it?
I have a few:

1. For config registered in the DI we could use data annotations / fluent validation to validate, to some extent replicating what regular ASP.NET IOptions offer. It would have the benefit of reusability esp for the common packages (PushNotifications / SendGrid / KeyVault). But it won't work for configuration not injected to DI, e.g. connection strings.
2. Some validation when reading data from IConfiguration e.g. when the requested key is not set, but it would be hard to cover all IConfiguration api surface.
3. Some checks would have to be mandatory (and crash app on startup), but some would have to be optional and just trigger warning, e.g. to facilitate development/integration tests. Maybe it has to be dependent on the environment level - be strict on production, but only warn on dev/test.

[jakubfijalkowski]

Regarding your points

1. I don't like that. Configuration validation is, IMO, responsibility of the app and not of the modules (it will be painful to modify the behavior). I don't think we should have DI involved here at all and we shouldn't use anything IOption-like.
2. You don't need to use IConfiguration. We're already using custom Config class and that's all that we need to use to validate the configuration IMO.
3. It has to be done differently on test/prod & on dev. I, for example, tend to use as few secrets as I can so that I'm not dependent on network access or just don't send unwanted e-mails.

Let's start small, with just a basic checks & some general rules regarding that (i.e. predefined exceptions/helper methods like EnsureExistsOnTest(Func<IConfiguration, string> getter)).