C# 在 app.config 中使用 XML 包含或配置引用来包含其他配置文件的设置
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/480538/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Use XML includes or config references in app.config to include other config files' settings
提问by TheSoftwareJedi
I have standard logging, NHibernate, etc. configuration blocks in my app.config
and I'd like to extract them into a common XML file that can be included as a reference by all of my applications' app.config
files.
我有标准日志记录、NHibernate 等配置块,我app.config
想将它们提取到一个通用 XML 文件中,该文件可以作为我所有应用程序app.config
文件的参考。
Is this possible?
这可能吗?
采纳答案by TheSoftwareJedi
Yes, you can use the configSource
attribute of the configuration block. All configuration blocks have this attribute - although it isn't documented.
是的,您可以使用configSource
配置块的属性。所有配置块都具有此属性 - 尽管没有记录。
See this article, all the way at the bottom, appendix B. I've also pasted the relevant section below:
请参阅这篇文章,一直在底部,附录 B。我还粘贴了下面的相关部分:
Appendix B: including external configuration files
Despite all the greatness to be found in .NET 2.0's configuration features, there is one drawback. When working on a single project across multiple environments, managing configuration can become a nightmare. The process of managing multiple versions of a configuration file for multiple environments -- i.e. development, testing, staging and production -- at my current job involves manual comparisons of
.config
files whenever changes are deployed to one environment or another, with a manual merging process. I spent months trying to find a better way and eventually found one. Enter one of those oh-so beloved "undocumented" -- or in this case, just poorly documented -- features that Microsoft is so famous for:configSource
. I only came across this little gem when I was digging through the .NET 2.0 configuration source code with Reflector, wonderful little tool.Each configuration section, when parsed and loaded by the .NET configuration classes, is assigned a
SectionInformation
object. TheSectionInformation
object contains meta information about a configuration section and allows some management of how sections override each other when defined in a child config file (ASP.NET). For now, we will ignore the majority of what SectionInformation has to offer, save theConfigSource
property. By adding aconfigSource
attribute to the root element of anyConfigurationSection
, you can specify an alternate, external source from which the configuration settings will be loaded.<!-- SomeProgram.exe.config --> <configuration> <connectionStrings configSource="externalConfig/connectionStrings.config"/> </configuration> <!-- externalConfig/connectionStrings.config --> <connectionStrings> <add name="conn" connectionString="blahblah" /> </connectionStrings>
In the configuration file above, the
<connectionStrings>
section has been sourced from a file calledexternalConfig/connectionStrings.config
. All of the application's connection strings will be loaded from the specified file. Now that the connection strings are loaded from an external resource, it is a relatively simple matter to create aconnectionStrings.config
file in each environment at the same relative location. Hence, theexternalConfig/
part of theconnectionStrings.config
path. The beauty here is that we can define connection strings properly for each environment once. We do not have to worry about accidentally overriding those settings during a deployment where a config file was either merged improperly or not merged at all. This can be a huge boon when deploying changes in an application to a production environment, where it is critical that the correct database connection strings exist. The downfall of using theconfigSource
attribute is that it requires all configuration settings to be placed in the external file. No inheritance or overriding is possible, which in some cases makes it useless. All external configuration files used with theconfigSource
attribute must also reside in a relative child path to the main.config
file. I believe this is in regards to security concerns with storing the file in a relative parent path in a web environment.Something else to note is that the
<appSettings>
section has a better alternative to usingconfigSource
, called file. If you use the file attribute rather than configSource with the<appSettings>
section, you can define settings in both the root.config
file and in the referenced file. Settings from the root.config
file may also be overridden in the referenced file, simply by adding something with the same key. Sadly, the file attribute is only available on the<appSettings>
section and is not built into the configuration framework. It is possible to implement a similar attribute in your own configuration sections. This will be discussed in a future installment of advanced configuration topics, after several prerequisite installments ;).
附录 B:包括外部配置文件
尽管在 .NET 2.0 的配置特性中发现了所有的伟大之处,但还是有一个缺点。在跨多个环境处理单个项目时,管理配置可能成为一场噩梦。在我目前的工作中,为多个环境管理配置文件的多个版本的过程——即开发、测试、登台和生产——涉及
.config
在将更改部署到一个或另一个环境时手动比较文件,以及手动合并过程。我花了几个月的时间试图找到一种更好的方法,最终找到了一种方法。输入其中一个非常受欢迎的“未记录” - 或者在这种情况下,只是记录不佳 - 微软非常有名的功能:configSource
. 我是在使用 Reflector(一个很棒的小工具)挖掘 .NET 2.0 配置源代码时才遇到这个小宝石的。每个配置节在被 .NET 配置类解析和加载时,都会被分配一个
SectionInformation
对象。该SectionInformation
对象包含有关配置节的元信息,并允许对在子配置文件 (ASP.NET) 中定义时节如何相互覆盖进行一些管理。现在,我们将忽略 SectionInformation 提供的大部分内容,保存ConfigSource
属性。通过向configSource
any 的根元素添加属性ConfigurationSection
,您可以指定一个备用的外部源,从中加载配置设置。<!-- SomeProgram.exe.config --> <configuration> <connectionStrings configSource="externalConfig/connectionStrings.config"/> </configuration> <!-- externalConfig/connectionStrings.config --> <connectionStrings> <add name="conn" connectionString="blahblah" /> </connectionStrings>
在上面的配置文件中,该
<connectionStrings>
部分来自一个名为externalConfig/connectionStrings.config
. 将从指定的文件加载应用程序的所有连接字符串。既然连接字符串是从外部资源加载的,那么connectionStrings.config
在每个环境中的相同相对位置创建一个文件是一件相对简单的事情。因此,externalConfig/
部分connectionStrings.config
小路。这里的美妙之处在于我们可以为每个环境正确定义一次连接字符串。我们不必担心在配置文件合并不正确或根本没有合并的部署期间意外覆盖这些设置。在将应用程序中的更改部署到生产环境时,这可能是一个巨大的福音,其中存在正确的数据库连接字符串至关重要。使用该configSource
属性的缺点是它需要将所有配置设置放在外部文件中。无法继承或覆盖,这在某些情况下使其无用。与configSource
属性一起使用的所有外部配置文件还必须驻留在主目录的相对子路径中.config
文件。我相信这是关于将文件存储在 Web 环境中的相对父路径中的安全问题。还有一点需要注意的是,该
<appSettings>
部分有一个更好的替代方法configSource
,称为 file。如果对<appSettings>
节使用文件属性而不是 configSource,则可以在根.config
文件和引用文件中定义设置。根.config
文件中的设置也可以在引用文件中覆盖,只需添加具有相同密钥的内容即可。遗憾的是,文件属性仅在该<appSettings>
部分可用,并未内置到配置框架中。可以在您自己的配置部分中实现类似的属性。这将在以后的高级配置主题中讨论,在几个先决条件之后;)。