寻求一种明智的方法来构建 .Net Core 中的 appsettings.json 文件。
基础的 'appsettings.json' 文件应该配置为在开发环境中运行，然后基于环境的覆盖文件，例如 appsettings.production.json 会覆盖生产环境下的特定键值吗？
还是说 appsettings.json 只应包含在所有环境下共享的配置，然后使用特定的 appsettings.development/staging.json 文件来明确设置这些环境的键值？
我的担忧是，假设一个应用程序部署到一个实际服务器上，但缺少了存储在环境变量中的密钥（例如，要覆盖连接字符串），或者拼写错误等。在这种情况下，应用程序将退回到基础的 appsettings.json 连接字符串，这将是错误的数据库连接字符串使应用程序无法正常运行。这样的情况听起来相当糟糕，特别是因为这很容易被忽视？
因此，问题真正的关键在于 - 基本的 appsettings.json 文件的内容应该作为默认的“dev”值（例如 dev 数据库、沙盒 API）而被覆盖更新为生产数据，还是反过来？
appsettings.json、appsettings.{environment}.json、AzureAppConfig、KeyVault，最后是secrets.json。这样，无论如何，我都可以用我的本地secrets文件覆盖来自Azure的设置（即使我要覆盖的设置并不是技术上的机密）。program.cs中编写了一些自定义代码来处理从Azure加载配置源，然后查找具有Path为"secrets.json"的JsonConfigurationSource，最后将其提升为IConfigurationBuilder.Sources中的最后一项。
对我来说，我的文件用法如下
appsettings.json - 通用设置，需要为任何环境设置，并且根据环境可能永远不会更改。
appsettings.{environment}.json - 主要是空的JSON文件，基本上只命名了AzureAppConfig和AzuerKeyVault资源名称以连接到AzureAppConfig - 基本上适用于在生产、暂存/测试或本地开发之间有所不同的任何内容，并且不是敏感信息。API端点地址、IP地址、各种URL、错误日志信息等。AzureKeyVault - 任何敏感信息。用户名、密码、外部API的密钥（身份验证、许可证密钥、连接字符串等）。appsettings.json中设置了一个设置，也并不意味着您不能使用appsettings.{enviroment}.json或其他地方覆盖它。我经常在根设置文件中放置一个值为NULL的设置，只是为了提醒自己它是应用程序中使用的设置。因此，更好的问题可能是，您想能够仅使用基本的appsettings.json和secrets.json运行应用程序（例如无错误）吗？还是始终需要来自appsettings.{enviroment}.json的内容才能成功启动？Microsoft.Extensions.Options提供了各种方式来验证您的选项，以便您可以尝试并捕获留空/未定义某些内容的情况。我通常使用数据注释属性装饰我的POCO选项类，然后使用ValidateDataAnnotations()来验证它们是否正确设置。services.AddOptions<MailOptions>().Bind(configuration.GetSection("MailSettings")).ValidateDataAnnotations();
MailOptions 这样的东西时运行（因此不是在启动时）。
出于这个原因，我还创建了自己的 IStartupFilter，在应用程序启动时预先请求一个或多个我的选项类，以便在应用程序开始接受请求之前强制运行相同的验证。public class EagerOptionsValidationStartupFilter : IStartupFilter
{
public readonly ICollection<Type> EagerValidateTypes = new List<Type>();
private readonly IServiceProvider serviceProvider;
public EagerOptionsValidationStartupFilter(IServiceProvider serviceProvider)
{
this.serviceProvider = serviceProvider;
}
public Action<IApplicationBuilder> Configure(Action<IApplicationBuilder> next)
{
foreach (var eagerType in EagerValidateTypes)
{
dynamic test = serviceProvider.GetService(typeof(IOptions<>).MakeGenericType(eagerType));
_ = test.Value;
}
return next;
}
}
startup.cs
public void ConfigureServices(IServiceCollection services)
{
services.AddTransient<IStartupFilter>(x =>
new EagerOptionsValidationStartupFilter(x)
{
EagerValidateTypes = {
typeof(MailOptions),
typeof(OtherOptions),
typeof(MoreImportantOptions)
}
});
}
我认为这个问题的答案很无聊：这取决于具体情况。但我最喜欢的方法是：
appsetting.json (base settings)
appsettings.development.json (dev with no secrets)
appsettings.production.json (production with no secrets)
Appsettings 中，仅包含基本设置中的机密值，而其他值则写在对应的 appsettings.[env].json 文件中。例如，数据库连接密钥仅存在于基本设置中，与本地数据库一起使用。这是环境的任务去替换它。
数据库连接和日志记录的示例：
appsettings.json
{
"ConnectionStrings": {
“dbConnection: “data source=localhost” <—— only here
},
“environment”: “local”,
"Logging": {
"LogLevel": {
"Default": “Verbose”
}
},
}
appsettings.development.json
{
“environment”: “development”,
"Logging": {
"LogLevel": {
"Default": “Warning”
}
},
}
appsettings.production.json
{
“environment”: “production”,
"Logging": {
"LogLevel": {
"Default": “Information”
}
},
}
有几种方式可以配置你的设置（这正是.NET Core的美妙之处）。我通常采用以下方式：
appsetting.json (template)
appsettings.development.json (dev with no secrets)
实际上，我没有在 appsettings.json 中设置任何设置。我将其用作必须在部署期间设置的设置的模板映射。
// appsettings.json
{
"ConnectionStrings": {
"dbConnection": "************************"
},
"environment": "************************",
"Logging": {
"LogLevel": {
"Default": "************************"
}
},
}
这样，如果我错过了任何设置，它将在以后变得明显，因此我不必担心意外使用“滑过”层次结构的设置。因此，如果您查看其他Json文件，则它们是完整的，没有隐藏的设置。
// appsettings.Development.json
{
"ConnectionStrings": {
"dbConnection": "data source=localhost"
},
"environment": "local",
"Logging": {
"LogLevel": {
"Default": "Verbose"
}
}
}
在小型应用程序中，共享设置似乎是一个好主意。但如果您的应用程序变得更加复杂，它实际上会带来更多问题。
我已经开始摆脱appsettings.json并通常使用以下方式：
appsettings.local.json
appsettings.development.json
appsettings.staging.json
现在来运行命令，我可以使用$env:ASPNETCORE_ENVIRONMENT="local"或$env:ASPNETCORE_ENVIRONMENT="development"明确设置我的环境变量。
当我使用$env:ASPNETCORE_ENVIRONMENT时，我会得到一个清晰的响应，而之前，“无响应”让我不确定它将使用哪些设置 - 我也不会意外地在错误的环境中运行其他命令。
您还可以在launchsettings.json中设置环境变量以运行解决方案。
至于部署，您可以通过构建流水线处理它，或确保在web应用程序配置中设置了ASPNETCORE_ENVIRONMENT。
appsettings.json应该配置为在本地开发环境中运行尽可能多的内容。请注意：有时可能会存在第三方依赖项，您无法在本地启动（例如，应用/服务使用的第三方API服务），在这种情况下，我将提交特定设置的dev/sandbox值，但对于其他所有内容（例如，与数据库的连接、消息代理、idp、遥测堆栈等），我将进行本地配置。我还喜欢拥有一个初始化脚本，以快速启动所有应用程序依赖项。我在工作的公司使用的微服务模板使用PowerShell和docker-compose快速轻松地启动本地容器化依赖项，以便团队成员可以尽快启动并运行。
以下是采用上述方法的原因：
另外几个要点：
CONFIG_DIR和ASPNETCORE_ENVIRONMENT环境变量：WebHost.CreateDefaultBuilder(args)
.ConfigureAppConfiguration((context, builder) =>
{
string basePath = Environment.GetEnvironmentVariable("CONFIG_DIR") ?? Directory.GetCurrentDirectory();
string environmentVariable = Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT");
Console.WriteLine("Config directory: " + basePath + Environment.NewLine + "Environment: " + environmentVariable);
builder.SetBasePath(basePath);
builder.AddJsonFile("appsettings.json", false, true);
if (!string.IsNullOrEmpty(environmentVariable))
builder.AddJsonFile("appsettings." + environmentVariable + ".json", true, true);
builder.AddEnvironmentVariables();
})
/etc/opt/[name-of-service]，并且不应与二进制文件位于同一目录下的 /opt/[name-of-service] 中。这遵循 Linux 文件系统层次结构标准。前面提到的 CONFIG_DIR 环境变量就是为此而设。appsettings.docker.json 文件，以便在本地容器中运行我的应用程序/服务。当我想通过 docker 日志提供程序测试日志记录时，我会使用它来替代仅从 Visual Studio IDE 运行应用程序的情况。appsettings.*.json文件进行更改，从而导致某些问题。
此外，如果您考虑将相同的设置作为后备添加到appsettings.json中，那么为什么需要env变量呢？env出现故障
appsettings.json\dbConnection (dev)将被appsettings.production.json\dbConnection覆盖。dbConnection将直接从appsettings.production.json\dbConnection（或从您本地机器上的appsettings.development.json\dbConnection）中获取。appsettings.json中，它们仍将被相应文件中的值覆盖。或者不覆盖（如果没有）。无论如何。所以，我认为唯一的问题是：在appsettings.json中是否应该有任何不同于prod和dev环境的设置，还是只包含通用的设置？
而合理的答案是：它应该只包含通用设置。因为这是预期的。而且更方便-如果您需要更改prod或dev的设置，您不需要记住在哪里找到它们。显然，在appsettings.production.json 中为 prod ，在 appsettings.development.json 中为 dev 。此外，这更可预测-有一天，即使不是您，其他人也会花费一些时间尝试弄清楚为什么数据库连接失败，如果他眼前的连接字符串正确（因为在半夜他忘记检查是否被覆盖）。
这样做可以增加更多的灵活性，例如当环境变量是 DOTNET_ENVIRONMENT 而不是 ASPNETCORE_ENVIRONMENT 时（还有更多配置）。context.HostingEnvironment.EnvironmentName
appsettings.json作为开发活动基础的最佳方式的争论。请更多地关注你的问题，而不是询问处理appsettings.json时应该选择哪种策略。因此，在SO上一个好的问题应该避免将意见作为答案。 - Eriawan Kusumawardhono