Enable the ServiceDefaults project to contribute shared configuration to projects that reference it

[DamianEdwards]

The ServiceDefaults project today provides methods that are called from service projects to configure common defaults like metrics, HTTP client service discovery, health checks, etc. For some common concerns though, using the configuration system, e.g. JSON files, is the preferred.

We should enable the ServiceDefaults project to contribute to the configuration of the projects that reference it. This would be done in the following way:

• Have appsettings-shared.json and appsettings-shared.Development.json files in the ServiceDefaults project that shared configuration can be set in. Note the filename scheme here is specifically crafted to ensure compatibility with the existing scheme used in the default JSON configuration file sources added to most apps today, i.e. appsettings[.{EnvironmentName}.].json. Using '.' to separate the shared suffix would lead to ambiguity (is "shared" an environment name or sentinel for shared config?). Alternatively we could use a scheme like shared.appsettings[.{EnvironmentName}.].json
• A new package (e.g. Microsoft.Extensions.Configuration.Json.Shared) that would be referenced by the ServiceDefaults project that contains:
  • APIs to add the shared configuration sources to an app's configuration builder. The sources should be added before the app's own appsettings.json files to ensure that shared config does not override app-local config.
  • MSBuild targets that include the shared appsettings JSON files in the build output of the ServiceDefaults project (i.e. the project directly referencing the NuGet package)
  • MSBuild targets that flow transitively to projects that reference the ServiceDefaults project, that facilitate flowing details about the shared configuration JSON files to the app assemblies during inner-loop, such that the shared JSON files can be loaded directly from the ServiceDefaults project at runtime (rather than relying on file copying) and thus supporting editing of these files and having those changes reflected in real-time when running from Visual Studio, etc. (this is very similar to how StaticWebAssets works today in ASP.NET Core projects)

A partial implementation of this proposal can be seen in here. It doesn't use the MSBuild targets proposed (like StaticWebAssets) but rather facilitates the coordination from data injected by the DevHost project, but the other aspects are inline with what's proposed here.

[danmoseley]

@DamianEdwards is this still relevant? for 8.0

[DamianEdwards]

We can move post-GA to reassess then.