c# - 在 C# .NET Framework 中使用 ConfigurationBuilder 我的应用服务设置去了哪里？

Question

我正在尝试将源代码中的特定于环境的变量组合到App.config文件的现有配置以及AppSettings和ConnectionStrings中用于 Azure WebJob(.NET Framework)的 Azure 应用服务。在进行更改时，将所有环境变量都放在应用服务中可能会非常耗时。

在浏览了一堆关于 App.config-transformations 和 Azure WebJobs 主题的博客和帖子之后，添加 ConfigurationBuilder 似乎是覆盖环境特定(非 secret )设置的相当新的方法。如果我没记错的话，它是在 .NET 4.7.1 中添加的。它看起来比 SlowCheetah 和脚本更有前途。

但是添加自定义 ConfigurationBuilder 后(类似于链接 1 中提到的)应用服务中指定的应用设置不再包含在结果中。我最终只得到了 app.config 文件和自定义 ConfigurationBuilder 中的条目。在配置条目中创建自定义条目时是否需要检索这些应用程序设置？或者我应该扩展环境变量并修改那些 XmlNode 条目？

1. https://jeffreyfritz.com/2017/11/modern-configuration-for-asp-net-4-7-1-with-configurationbuilders/
2. https://learn.microsoft.com/en-us/dotnet/api/system.configuration.configurationbuilder?view=netframework-4.7.2

Answer 1

事实证明，在确定可能的路线之前，需要考虑一些事情并做出一些假设。我最终在documentation的帮助下编写了自己的配置生成器。 .

鉴于使用的是 .NETFramework 而不是 AspNetCore(在本例中具体为 .NETFramework 4.7.1)。 Azure 提供的应用服务似乎确实使用了某种开箱即用的配置生成器。似乎没有任何指定配置生成器的 Web.config 将包含所有 Azure 应用服务设置。它甚至会添加 Web.config 中不存在的设置。所以不使用脚手架；这可能会让事情变得更容易掌握，但微软可能有充分的理由不以这种方式实现事情。添加自己的配置生成器将使从 Azure 应用服务读取的任何设置不再被读取。我假设，可能是因为您刚刚替换了“隐藏”配置生成器，现在需要自己完成这项工作。

调查source code我做了另一个相关的发现，这对我编写自己的配置生成器有很大帮助。配置构建器的工作方式似乎有两种典型的操作模式:贪婪或“严格”。我建议不要同时使用两者。贪婪模式意味着添加在环境变量中找到的所有设置，无论该 key 最初是否存在于 Web.config 中。 “严格”模式意味着它仅替换从一开始就存在的键的值。

我最终从环境变量中读取了相关设置。但找到所使用的适当前缀的可靠文档有点棘手(尽管可以读取所有变量)。但最常见的are roughly (我认为):

• APPSETTING_(如果我没记错的话，相信这些对应于应用服务设置)
• SQLServerSQLCONNSTR_
• SQLAZURECONNSTR_

无论如何，在我的特定场景中，我在同一个槽中运行应用服务 Web 应用程序和 WebJob。将 Web 应用程序中的设置附加到 Web 作业似乎没有吸引力且不必要。因此，我编写了一个“严格”的配置生成器，它以谨慎的方式从源头级联所有设置。这意味着 Azure 应用服务中指定的任何设置也必须在 Web.config 中定义。如果接下来没有这样的设置，则包括所选配置的任何转换值。最后，使用了 Web.config 中的默认值。

总之，如果您在 .NETFramework 中编写自己的配置生成器，您可能需要做一些工作来包含应用服务应用设置或连接字符串。您可能想要研究类型化类或 ProcessRawXml 的 ConfigurationBuilder 类及其各自的方法 ProcessConfigurationSection，也许还可以查看一些 real world examples .