我正在尝试将源代码中的特定于环境的变量组合到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 条目?
最佳答案
事实证明,在确定可能的路线之前,需要考虑一些事情并做出一些假设。我最终在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 .
关于c# - 在 C# .NET Framework 中使用 ConfigurationBuilder 我的应用服务设置去了哪里?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/53749995/