Add loading of [ApplicationName].settings.json & [ApplicationName].settings.[EnvironmentName].json to default Host

[DamianEdwards]

Sibling issue for ASP.NET Core: dotnet/aspnetcore#61343

To better support the upcoming file-based apps scenario coming in .NET 10 with dotnet run app.cs, the Host defaults should be updated to support loading more JSON configuration files based on the application name (and environment name). This allows for multiple file-based apps to be located in the same directory and have separate configuration files. The existing defaults mean that shared configuration can be placed in the files using the existing naming scheme, i.e. appsettings.json.

For example, a file-based app like app.cs should by default attempt to load JSON configuration files from files named app.settings.json and app.settings.[EnvironmentName].json, (e.g. app.settings.Development.json). Additionally, project-based apps would get the same new behavior, so that a project like MyApp.csproj would by default attempt to load JSON configuration files from files named MyApp.settings.json and MyApp.settings.[EnvironmentName].json. In both cases, these files should be loaded after and in addition to the existing JSON file names that are loaded by the Host defaults.

The code in question is at

runtime/src/libraries/Microsoft.Extensions.Hosting/src/HostingHostBuilderExtensions.cs

Lines 241 to 242 in a2e1d21

	appConfigBuilder.AddJsonFile("appsettings.json", optional: true, reloadOnChange: reloadOnChange)
	.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true, reloadOnChange: reloadOnChange);

The new code to add after these lines would be something like:

config.AddJsonFile($"{env.ApplicationName}.settings.json", optional: true, reloadOnChange: true)
      .AddJsonFile($"{env.ApplicationName}.settings.{env.EnvironmentName}.json", optional: true, reloadOnChange: true);

Alternatives

The naming scheme proposed uses settings as the common term indicating what the file is for. This was changed from the existing appsettings simply to make it a bit smaller as doing so arguably doesn't meaningfully change the understandability. We could take this opportunity to choose a different term though.

config might better be an interesting choice so as to align with the fact that the entries in this file are loaded by the configuration APIs, e.g. app.config.json. When coupled with dotnet/sdk#48200 that would yield the following files:

- myapp/
  - app.cs
  - app.config.json
  - app.run.json

Of course we could instead continue to use the established appsettings term, resulting in:

- myapp/
  - app.cs
  - app.appsettings.json
  - app.run.json

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-extensions-hosting
See info in area-owners.md if you want to be subscribed.

[KalleOlaviNiemitalo]

This looks like IHostEnvironment.ApplicationName (or IHostingEnvironment.ApplicationName) may be null or an empty string in some cases:

runtime/src/libraries/Microsoft.Extensions.Hosting/src/HostBuilder.cs

Lines 235 to 245 in 819bff1

	string? applicationName = hostConfiguration[HostDefaults.ApplicationKey];
	if (string.IsNullOrEmpty(applicationName))
	{
	// Note GetEntryAssembly returns null for the net4x console test runner.
	applicationName = Assembly.GetEntryAssembly()?.GetName().Name;
	}
	if (applicationName is not null)
	{
	hostingEnvironment.ApplicationName = applicationName;
	}

If that happens, I think it's better to skip the extra AddJsonFile calls than load dotfiles like .settings.json.

[ericstj]

cc @halter73, @Tratcher, @steveharter

@DamianEdwards this isn't API but does this need to go through any sort of experience design review to ensure that other stakeholders agree with the new default conventions?

[DamianEdwards]

@ericstj happy to do what we think is required. How do we want to approach changing defaults like this, given it's not strictly API changes? Shall we use the API review process anyway, or would you prefer I setup a specific meeting to review this proposal?

[ericstj]

I don't think we need API review for this since it doesn't really fit that template / set of concerns. Lets determine who needs to sign off on it and call a meeting.

[DamianEdwards]

After chatting with @davidfowl about this, I'm revising the proposal so that this new file naming scheme would be mutually exclusive to the existing one, so rather than settings in [ApplicationName].settings.json overriding those in [appsettings.json], the naming scheme would be selected based on file existence. This way, the existing naming scheme has precedent so if any files exist matching that scheme it would be used, otherwise if any files exist matching this naming scheme, it is used. This way we can't break any existing apps.

@KalleOlaviNiemitalo your idea was interesting to me but I'd like to make the settings file with no app name (in this new naming scheme) be shared settings (and I'm not convinced with the dot prefix, need more convincing on that as my understanding is they're treated as hidden on non-Windows platforms by default), so that app-specific files override values in the shared settings file, i.e. the load order would be:

• settings.json
• settings.[EnvironmentName].json
• [ApplicationName].settings.json
• [ApplicationName].[EnvironmentName].settings.json

[KalleOlaviNiemitalo]

@DamianEdwards it seems you misunderstood what I wrote.

I mean, if both ApplicationName and EnvironmentName are non-empty strings, then the load order could be:

1. appSettings.json (not settings.json)
2. appSettings.[EnvironmentName].json
3. [ApplicationName].settings.json
4. [ApplicationName].[EnvironmentName].settings.json

But if ApplicationName is empty or null for any reason, then the load order should not be:

1. appSettings.json
2. appSettings.[EnvironmentName].json
3. .settings.json
4. .[EnvironmentName].settings.json

Instead, it should be:

1. appSettings.json
2. appSettings.[EnvironmentName].json