如何在.NET应用中正确使用Azure App Service应用设置

.NET Framework 场景下 ConfigurationManager 的作用 #

• 这个场景下的逻辑非常明确：不需要编写任何额外配置读取代码，ConfigurationManager 就可以直接读取到 App Service 门户配置的应用设置、连接字符串。
• 这个能力的核心不是 ConfigurationManager 主动对接了 App Service 接口，而是 App Service 的 IIS 宿主在应用工作进程（w3wp.exe）启动前，就会把门户配置的所有值直接注入到当前 AppDomain 的配置集合中，且注入值的优先级高于 web.config 中的同名配置项。
• 这套机制完全兼容标准 ASP.NET 配置读取模式：本地调试时读取 web.config 的值，部署到云上自动读取 App Service 注入的生产值，不需要修改任何代码，天然支持密钥脱离代码仓库存储。

.NET Core/.NET 5+ 场景下 ConfigurationBuilder 的配置要求 #

• 如果你像示例中那样完全手动初始化 ConfigurationBuilder，仅添加 JSON 配置文件源、没有调用 .AddEnvironmentVariables()，确实无法读取到 App Service 注入的配置。
• 原因很简单：.NET Core 之后的配置框架是按添加的源顺序组合读取的，添加了什么源才能读取对应源的配置；如果没加环境变量源，就算平台把配置注入成了进程环境变量，代码也不会主动读取这部分值。
• 如果你使用官方默认的 Web 应用模板（即直接调用 WebApplication.CreateBuilder(args) 初始化主机），框架内部已经默认按优先级添加了环境变量配置源，不需要手动追加 .AddEnvironmentVariables() 调用，App Service 的配置可以正常生效，且优先级高于 appsettings.json 中的同名配置。

App Service 配置注入逻辑与前缀规则 #

• 配置注入是 App Service 平台层面的默认行为，和应用使用的技术栈无关：只要是部署在 App Service 上的应用，不管是 .NET、Java、Node.js 还是 Python，平台都会把门户配置的应用设置、连接字符串作为进程级环境变量注入到应用运行进程中。
• 应用能不能读到这些值，只取决于使用的配置框架有没有把环境变量纳入读取范围：
  • .NET Framework 由 IIS 宿主直接把值灌进 ConfigurationManager 的配置集合，不需要应用做任何主动配置
  • .NET Core/.NET 5+ 需要在 ConfigurationBuilder 中添加环境变量配置源，才能读取到注入的值
• 关于 APPSETTING_ 前缀的差异：
  • 这个前缀是平台注入环境变量时自动追加的系统前缀，在门户配置应用设置时不需要手动添加。比如你在门户配置键为Test、值为123的应用设置，平台会自动生成名为APPSETTING_Test=123的环境变量：针对 .NET Framework 应用，平台会直接把Test键映射到ConfigurationManager.AppSettings集合；针对 .NET Core 应用，如果调用.AddEnvironmentVariables("APPSETTING_")指定前缀过滤，框架会自动去掉前缀，直接用Configuration["Test"]就能拿到值，和本地 appsettings.json 的键名完全对齐。
  • 如果你手动在门户给键名加了APPSETTING_前缀，比如配置键为APPSETTING_Test，平台注入时会再次追加前缀，生成名为APPSETTING_APPSETTING_Test=123的环境变量。这时候不管是用 .NET Framework 的ConfigurationManager.AppSettings["Test"]，还是 .NET Core 加了APPSETTING_前缀过滤后读Test，都拿不到值，必须读取完整的APPSETTING_Test键才能获取值，会导致本地和云端配置键不匹配，属于错误配置方式，完全不推荐。

两个配置示例的实际效果差异：

1. 配置name: "Test"：符合平台预期，代码中直接读Test键即可拿到值，本地、云端配置逻辑一致
2. 配置name: "APPSETTING_Test"：属于重复加前缀的错误配置，代码需要读APPSETTING_Test键才能拿到值，和本地开发配置无法对齐

内容的提问来源于stack exchange，提问作者Nmaster88