使用XML包括或app.config中配置的参考，包括其他配置文件的设置 [英] Use XML includes or config references in app.config to include other config files' settings

问题描述

我有标准的日志，NHibernate的，等等配置块在我的app.config，我想解压缩到可作为参考用我所有的应用程序的app.config文件。一个普通的XML文件

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.

这可能吗？

推荐答案

是的，你可以使用配置块的configSection属性。所有的配置块都有这个属性 - 虽然它不记录

Yes, you can use the configSection attribute of the configuration block. All configuration blocks have this attribute - although it isn't documented.

请参阅这篇文章，所有的方式在底部，附录B.我以前也粘贴了以下相关内容：

See this article, all the way at the bottom, appendix B. I've also pasted the relevant section below:

附录B：包括外部配置文件

尽管所有的伟大被发现在.NET 2.0的配置功能，有一个缺点。跨多个环境的单一项目时，管理配置可以成为一场噩梦。即开发，测试，分期和生产 ​​- - 管理多个版本的多个环境配置文件的过程中，在我现在的工作涉及到.config文件手动比较更改时被部署到一个环境或其他，具有手动合并处理。我花了几个月试图找到一个更好的办法，最终找到了一个。输入这些哦，让心爱的无证一 - 或在这种情况下，只是不良记录 - 的功能，微软是如此出名：configSource。我只是碰到这个小宝石，当我挖通过.NET 2.0配置源$ C ​​$ C与反射，奇妙的小工具。

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.

每个配置部分，当解析和由.NET配置类装载，被分配一个SectionInformation对象。该SectionInformation对象包含配置节的元信息，并允许部分如何超越对方时，在孩子的配置文件（ASP.NET）定义了一些管理。现在，我们将忽略大多数什么SectionInformation所提供，保存ConfigSource财产。通过添加一个configSource属性的任何配置节的根元素，你可以指定一个备用，从中将被加载的配置设置外部源。

Each configuration section, when parsed and loaded by the .NET configuration classes, is assigned a SectionInformation object. The SectionInformation 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 the ConfigSource property. By adding a configSource attribute to the root element of any ConfigurationSection, 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>

在上面的配置文件，在＆LT;的ConnectionStrings＆GT; 部分已经来源于一个名为externalConfig / connectionStrings.config文件。所有应用程序的连接字符串会从指定的文件中加载。现在连接字符串从外部资源加载，它是一个相对简单的事情，在相同的相对位置，以创建在每个环境一个connectionStrings.config文件。因此，externalConfig /所述connectionStrings.config路径的一部分。这里的美妙之处在于，我们可以正确地定义连接字符串一次为每个环境。我们没有部署在那里的配置文件要么是合并在所有不当或不合并过程中不用担心不小心覆盖这些设置。在应用到生产环境中部署的变化时，这是一个巨大的福音，是正确的数据库连接字符串不存在，这是非常关键的。使用configSource属性的缺陷是它需要所有的配置设置以放置在外部文件中。没有继承或压倒一切的是可能的，在某些情况下，使之无用。与configSource属性中使用的所有外部配置文件也必须驻留在一个相对子路径主要config文件。我相信这是关于安全问题与存储在一个相对父路径的文件在网络环境中。

In the configuration file above, the <connectionStrings> section has been sourced from a file called externalConfig/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 a connectionStrings.config file in each environment at the same relative location. Hence, the externalConfig/ part of the connectionStrings.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, were it is critical that the correct database connection strings exist. The downfall of using the configSource 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 the configSource 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.

另外需要注意的是，＆LT;的appSettings＆GT; 部分必须使用configSource，文件称为一个更好的选择。如果您使用的文件的属性，而不是configSource与＆LT;的appSettings＆GT; 部分，您可以定义在两个根config文件和引用文件中的设置。从根config文件的设置也可以被引用的文件中重写，只需添加一些使用相同的密钥。可悲的是，该文件的属性只适用于＆LT;的appSettings＆GT; 部分并没有内置到配置框架。它有可能在自己的配置部分，以实现类似的属性。这将在高级配置主题以后的文章中讨论，几个prerequisite分期付款后。）

Something else to note is that the <appSettings> section has a better alternative to using configSource, 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 ;).

这篇关于使用XML包括或app.config中配置的参考，包括其他配置文件的设置的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！