dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
35.19k stars 9.93k forks source link

Consistent naming of settings files #57509

Closed glen-84 closed 1 week ago

glen-84 commented 2 weeks ago

Is there an existing issue for this?

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

There are currently two such files:

Issues:

Describe the solution you'd like

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

Additional context

No response

martincostello commented 2 weeks ago

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 commented 2 weeks ago

This would be breaking in multiple ways

The loader would just need to:

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 commented 1 week ago

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.