Consistent naming of settings files

[glen-84]

Is there an existing issue for this?

• [X] I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

There are currently two such files:

• launchSettings.json
• appsettings.Development.json

Issues:

• The first is camelCased, the second is not.
  • Without a word separator or change in case, it is less easy to read, and cannot be spell checked.
• The second uses a TitleCased environment name (f.e. Development).
  • Most non-code files (think .editorconfig, .gitignore, packages.lock.json, etc.) are all lower-case.

Describe the solution you'd like

I suggest standardizing on lower-case-hyphenated naming for non-code files to solve these issues:

• launch-settings.json
• app-settings.development.json

Additional context

No response

[martincostello]

I think this ship has long since sailed on making on change to this, even if it was desired.

This would be breaking in multiple ways (case sensitive file systems, all users needing to rename their files, environment names needing to be changed as the case no longer matches, etc.) so would be an expensive change to make across multiple repositories (aspnetcore, runtime, sdk, others?) and tools (e.g. Visual Studio, Visual Studio Code, Rider?).

The reason to change it seems more about personal preference (e.g. camelCase vs kebab-case) and I doubt it justifies the development cost of the change to .NET and all its many users.

[glen-84]

This would be breaking in multiple ways

The loader would just need to:

• Try the hyphenated version first (launch-settings.json).
• Fall back to launchSettings.json, and log a deprecation notice.

That's non-breaking.

The environment name could surely be matched in a case-insensitive manner?

The reason to change it seems more about personal preference (e.g. camelCase vs kebab-case)

No, it's about consistency and clarity, not about personal preference. If the preference were camelCase, then it would be appSettings.json. Still, that's again inconsistent with other files (it's not .editorConfig or .gitIgnore, for example), but at least it would be consistent within the framework itself.

[amcasey]

Consistency can be trickier than it appears. In this case, my guess would be that appsettings came first and then launchSettings was adopted to maintain consistency with VS Code.

While I also find this sort of inconsistency bothersome, I can't say that I find it unclear.

In the absence of a way to make configuration files consistent across the board, I'm not convinced there's sufficient value in changing these two particular files to justify the development cost and the potential for user confusion.