Configuration Settings

[avanderhoorn]

Design:

Inspiration for this design is based on the supported configuration system for DNXRE and how MVC utilizes this.

Use Case

• Options - Provided by the dnxre, allows for handling Typed Configurations
  • When order of given collection of extensions is required
  • Chain of evaluation which doesn't run through the whole collection unless needed
  • When setting of typed primitive values for configuration is required
  • Defining authentication tokens or timeouts
  • When using a given binary extension provider is context specific
  • You want to use file system provider in one context vs a db provider in another context
• Dependency Injection - Provided by the dnxre, allows for adding/replacing Providers/Extensions that are registered
  • When order of given collection of extensions is not required
  • When discovering all instances that the user has already registered with the container
  • When using a given binary extension provider is not context specific
  • You want to replace how a given dp provider operates
• Configuration - Provided by the dnxre, allows for changing setting without recompile (where applicable, typically applied over the Options)
  • When setting of untyped primitive values for configuration is required
  • Defining authentication tokens or timeouts
  • When settings of values needs to be done without a recompile
• Custom Hooks - Requires custom coding, allows for explicit control when needed
  • When specialised extensions are needed are needed

Implementation

• Options
  • Descriptor's are used for any List<> properties for the GlimpseOptions to control lazy loading - see
  • Extension methods can be used to configure how options are setup - see
  • Providers will be used to pull the instance's out of the Options and active any Descriptors - see & see & see
  • Items registered here, can also have additional options properties that they depend on
  • For example, options.ModelBinders has BodyModelBinder see registered as one of its items (options.ModelBinders.Add(typeof(BodyModelBinder)); see and it intern injects DefaultValidationExcludeFiltersProvider see which is the only consumer of options.ValidationExcludeFilters
  • This means that if DefaultValidationExcludeFiltersProvider gets replaced by something else that implements IValidationExcludeFiltersProvider, options.ValidationExcludeFilters wont be used by anything... this is ok
• Dependency Injection
  • Types/instances are registered with the container with a specific lifetime specified
  • To "configure" these types, you use services.Replace(...) to override the default registration - see & see
  • Providers are typically registered via this means and depending on implementation they might leverage the Options infrastructure or provide wiring up to Custom Hooks - see
• Configuration
  • These settings can either be applied before or after the coded configuration
  • Leverages IConfiguration to pull out the settings from the users config source - see
  • Typically pull out config and put into Dictionary<string, string>, from there the data is pulled into a typed object - see & see
• Custom Hooks
  • Providers are still used, in most cases will have a Default provider which uses the convention and a FixedSet which allows for fixed values to be provided
  • Options are explicitly not being used in convention scenarios to help avoid confusion and streamline the process
  • FixedSet providers are populated via extension methods which are extend off the IServiceCollection
  • Default providers scan through the assemblies looking for types at play

Examples

• Options
  • Usage - Startup & Startup
  • Definition - MvcOptions & RazorViewEngineOptions
  • Setup - MvcOptionsSetup & RazorViewEngineOptionsSetup
• Dependency Injection
  • Registration - MvcServices
  • Provider - DefaultModelMetadataProvider
• Configuration
  • Processing - DbContextOptionsParser
  • Setup - EntityFrameworkServicesBuilder
• Custom Hooks
  • Usage - Startup
  • Setup - MvcServiceCollectionExtensions
  • Providers - DefaultControllerTypeProvider & FixedSetControllerTypeProvider

State The Application Model is a model that might not be needed by provides a unified view of the complete discovery process.

Guidelines:

• A Descriptor Provider is used to build the Application Model - also see
• Model contains not only the master list of finial processing, but the metadata around
• ...

  Implementation

Server Web:

• [x] Security policies (which requests are allowed access vs not) - Collection - Dynamic discovery - Hard coded
  • [x] LocalHostOnly - bool Agent Web:
• [x] Runtime policies (which requests should be profiled vs not) - Black/white listed - Collection - Dynamic discovery - Hard coded
  • [x] Uri's - Black/white listed - Collection - Static discovery - Extension methods
  • [x] Status Code - Black/white listed - Collection - Static discovery - Extension methods
  • [x] Content Type - Black/white listed - Collection - Static discovery - Extension methods
• ...

[CGijbels]

@avanderhoorn I've worked on a branch regarding the code configuration for Glimpse. It is already functional and fully backward compatible with the current glimpse configurations, it allows for configuration to be defined externally (database, server, custom config files, ...) and provides out of the box a provider based on xml configuration file as this is how users configured glimpse up until now. Adding another default to deal with json configs etc... is just a small step...

I definitely am going to take a look at what you described above, maybe things can be mapped, maybe not...

I didn't make a PR yet of that branch, as I wanted to finish it further to make sure I didn't overlook things, but then I had to take a little break on my work :-(

Have a look at the branch to get an idea about how it works, and I can always give a quick guide over Skype or so if you want too

[avanderhoorn]

@CGijbels more than happy to talk it over and see what we can do. My main thinking here is that the config/options in vNext is very different to what it was with classic ASP.Net. I know that we (mainly you) put a huge amount of effort into the config system in the old v2 code base, but with the advent of vNext and how different it is, I'm not sure what else we can do. For instance the next version of MVC is built solely on the base support, web.config doesn't exist, code configurations are preferred over json/environment/etc configurations (particularly when it comes to complex cases, type based black/white listing, etc), dependency injection which is at the core of vNext is a fairly fundamental part of vNext, etc, etc. When looking at this I struggled to see how what we did would natively/cleanly come across. Any ideas?

[CGijbels]

web.config doesn't exist, code configurations are preferred over json/environment/etc configurations (particularly when it comes to complex cases, type based black/white listing, etc)

the configuration has been built to allow any kind of source for the configuration settings to start with, after which configuration to code can be added as well. So for vNext it might be enough to implement the IConfigurationSettingsProvider although the hook for that lies in setting the provider to use, through the config, as you can see in the (ConfigurationFactory)[https://github.com/Glimpse/Glimpse/blob/glimpse-configuration-system-refactoring/source/Glimpse.Core/Configuration/ConfigurationFactory.cs] class. Now on the other hand, by specifying a IConfigurationSettingsProvider in a ConfigurationFactory.Create overload might be enough, as that Create method is called by the hosting environment (ASP.Net, OWIN Middleware (see here ,...)

So as long as the hook into the new MVC provides an IConfigurationSettingsProvider to the ConfigurationFactory all should be good to go, and that IConfigurationSettingsProvider can be quite basic as well because code configuration then happens on the resulting ConfigurationSettings

Just wondering, but even with the advent of ASP.NET vNext etc... we only need to provide the hooks into the runtime and maybe other plugins, but we still share the Glimpse Core? Or is the idea to have 2 Glimpse Core's maintained next to each other? Because the majority of users will still be using ASP.NET vCurrent for the upcoming year(s)...