Core 3.1中的应用程序设置如何在多环境场景中工作

目录

介绍

背景

应用程序设置示例

使用代码

AppSettings.json

AppSettings.dev.json

AppSettings.Development.json

AppSettings.prod.json

ApplSettings.qa.json

兴趣点

 

介绍

多环境是我们在企业中开发软件的过程中非常常见的情况。NET Core 3.1放弃了经典的 Web Config 以使用.json文件，但它超越了它，为开发人员提供了一种非常灵活的方式来在多个环境中配置应用程序。本文探讨Core如何管理此设置以及开发人员如何充分利用它。

.NET Core 3.1允许多个AppSetting允许我们在不同环境中轻松配置应用程序。使用AppSettings.EnvironmentName.json 约定区分每个AppSetting文件 。

下载代码演示

背景

Core以如下形式组织AppSettings：

• 一个Appsettings.json
• 几个可选的AppSettings.environment.json

Core 以下列方式管理这些文件：

• 该AppSettings.json总是考虑在应用程序中使用。
• 根据.NET变量的值仅选择一个环境文件：ASPNETCORE_ENVIRONMENT

此选定文件与常规AppSettings.json合并。在合并中，应用以下规则：

• 两个文件的所有值都进入最终设置。
• 如果两个文件中都有一个值，则环境设置文件的值优先并用于应用程序设置。

应用程序设置示例

让我们看一个实际的例子。我们有一个包含两个条目的AppSettings.json：

• environment = default
• var1 = default

以及包含以下条目的AppSettings.dev.json：

• environment = dev-environment
• var2 = dev

如下图所示。

如果ASPNETCORE_ENVIRONMENT变量的值为dev，那么当我们构建应用程序时，会选择AppSettings.dev.json并与AppSetting.json合并，如下所示：

 

作为此操作的结果，配置变量如下：

• environment= dev-environment：因为它们在两个文件中，并且dev的值优先于AppSettings.json
• var1=default：因为它存在于Appsettings.json中
• var2= dev: 因为它存在于AppSettings.dev.json

使用代码

下载代码演示

要对此进行测试，您可以使用本文附带的项目。让我简要解释一下。

该项目是NET Core 3.1 API的简单API模板，您可以在Visual Studio(TM) 2019中找到它，我们对其进行了修改以最好地展示其AppSettings工作原理。

我们向项目中添加了三个额外的AppSettings文件，以便在三种不同的环境中使用。这是软件开发商公司的正常情况。

 

现在我们使用以下变量配置环境：

AppSettings.json

 

{
  "environment": "default",
  "var1": "default"
}

 

{
  "environment": "dev-environment",
  "var2": "dev"
}

 

{
  "environment": "Development",
  "var3": "development"
}

 

{
  "environment": "Production",
    "var4": "production"
}

 

{
  "environment": "QA",
  "var5": "qa"
}

我们在这个应用程序中创建了一个服务来读取应用程序在运行时使用的配置。这使我们能够知道应用程序运行时真正使用了什么。

/// 
 /// Get the real value of the settings
 /// 
 /// 
 [HttpGet]
 [ProducesResponseType(typeof(string), StatusCodes.Status200OK)]
 public IActionResult Get()
 {
     string env = config["environment"];
     string var1 = config["var1"];
     string var2 = config["var2"];
     string var3 = config["var3"];
     string var4 = config["var4"];
     string var5 = config["var5"];

     string ret = Environment.NewLine;
     return Ok($"Environment: {env}{ret}var1:
     {var1}{ret}var2: {var2}{ret}var3: {var3}{ret}var4: {var4}{ret}var5: {var5}");
 }

 

"API Prod": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "launchUrl": "api/Configuration",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Prod"
      }
    },
    "API Dev": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "launchUrl": "api/Configuration",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Dev"
      }
    },
    "API QA": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "launchUrl": "api/Configuration",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "QA"
      }
    },

你应该得到这个：

Environment: dev-environment
var1: default
var2: dev
var3: 
var4: 
var5:

如果我们运行 QA，结果会有所不同：

Environment: QA
var1: default
var2: 
var3: 
var4: 
var5: qa

兴趣点

正如我们所看到的，你放在AppSettings.json中的所有变量都应该在所有环境中使用，除了该变量也存在于AppSettings.environment.json中。

组织我们的配置的一种替代方法是将每个缺陷的所有值都放在AppSettings.json中，并在其他配置中重复根据环境而变化的那些值。这个组织看起来很有吸引力，但在我看来会导致现实生活中的问题。

我的建议是在AppSettings.json中放入所有配置中相同的值。并放入AppSettings.environment.json，这些值在每个环境中都会发生变化。

这让你更容易得到错误，因为你忘记了一个值，没有默认值，并且服务失败，如果你有机会纠正它。

如果您按缺陷取值，程序可能仍然有效，但是当您在供多个开发人员使用的测试环境中部署时，错误值会造成混淆错误。

例如，您可以指向生产中的URL和QA中的其他URL，如果您将QA的URL放在AppSettings.json中而忘记投入生产，则程序会默默地获取QA值，您无法知道配置是否正确。

如果每个缺陷没有值，您可以防止程序使用有缺陷的配置，例如，在健康检查过程中，您可以检测到URL不正确。

https://www.codeproject.com/Articles/5297151/How-Does-the-Application-settings-in-Core-3-1-Work