Configuration as specified in config.json should be able to handle arrays

[rkeithhill]

In switching to JSON, I thought my AppSettings would get a bit cleaner. In my web.config file I store an array of small objects (Text, ControllerName, ActionName) as a string of JSON. When I read in that setting, I throw it at JSON to parse out the bits of the elements of this array of objects. But when I put this into config.json, I get an "Unsupported JSON token 'StartArray' was found" at startup. Why? It is valid JSON. Why arbitrarily restrict the form? What if one of my settings needs to be an array of objects e.g.:

{
  "AppSettings": {
    "NavBarLinks": [
      { "Text": "A", "Controller": "Fe" },
      { "Text": "B", "Controller": "Fi" },
      { "Text": "C", "Controller": "Fo" },
      { "Text": "D", "Controller": "Fum" }
    ]
  }
}

So now I'm back to encoding JSON inside the string value of a JSON field. Only now I have to escape every double quote. Blech.

[dmccaffery]

I suspect that this has to do with @shanselman insistence that the configuration API supports INI files, which is forcing the configuration to still be a flat list of name/value key pairs. 👎 for you, the lesser of the lesser Scotts. lol.

In all seriousness, though; while JSON supports a hierarchical data structure quite well, the new configuration API is designed to source configuration settings from anywhere -- like a database, or a web service, or an INI file, or a JSON file, or XML, or from a raw TCP service hosted via DNX on a Raspberry Pi... or, whatever. Introducing a hierarchical data structure would make the configuration interface considerably and unnecessarily more complex for those data stores that do not natively support a hierarchical data structure.

TL;DR I don't think that configuration was meant to be a replacement for a data-driven menu system, as per your example. It was meant as a replacement for the and of old. Simple name/value key pairs.

[rkeithhill]

But even the old web.config had more structure to it than name/value pairs (outside of AppSettings). And you could write a config section handler for your own custom structure. I wonder if that concept could be applied here?

[dmccaffery]

As far as I know, configuration sections have been eliminated from CoreCLR. Config sections were reliant on XML as a data structure and do not reliably and safely equate to all of the different types of sources for configuration data that the new configuration system wants to support.

Simplifying the configuration model makes it considerably easier to support configuration data from any source and it is important that these sources remain fully interchangeable (INI/CLI args/XML/JSON/etc.).

That being said, there is nothing stopping you from creating your own service used to store/retrieve hierarchical data in a flat JSON file and injecting it via DI without relying on the new configuration model. It sounds like you are in need of a more domain-specific language for configuration; and the configSection's of old aren't the best way to achieve that in the modern world.

You can even use DI within an MVC view.

[Eilon]

The intention of the Configuration APIs is that they're all very simple string-to-string mappings. However, in the OptionsModel system we have an ability to "bind" a strongly-typed options POCO object to config, and that includes both dictionary and array support, in addition to simple type conversions (bool, int, etc.).

Check out the unit tests added in the PR that added this feature to see how to use it: aspnet/Options#59

[rkeithhill]

@Eilon This is interesting but I seem to be precluded from using JsonConfigurationSource() with a new JSON file (menu.json). It still errors with unsupported JSON token StartArray. I think I'll go with @dmccaffery suggestion and role my own custom appsettings.json solution.

[davidfowl]

@rkeitghill that sounds good. You're likely seeing the error because this is a new feature (beta5+) and you have an older package