我有标准的日志记录,NHibernate等配置块,我app.config想将它们提取到一个通用的XML文件中,可以作为我所有应用程序app.config文件的参考.
这可能吗？
是的,您可以使用configSource配置块的属性.所有配置块都具有此属性 - 尽管未记录.
在底部,附录B中一直看到这篇文章.我还粘贴了以下相关部分:
附录B:包括外部配置文件
尽管在.NET 2.0的配置功能中有很多优点,但有一个缺点.在跨多个环境处理单个项目时,管理配置可能会成为一场噩梦.在我目前的工作中管理多个环境的配置文件的多个版本(即开发,测试,登台和生产)的过程涉及
.config在将更改部署到一个或多个环境时通过手动合并过程手动比较文件.我花了几个月的时间试图寻找更好的方法并最终找到了一个.输入其中一个非常受欢迎的"未记录的" - 或者在这种情况下,只是记录不佳 - 这些功能是微软着名的:configSource.当我使用Reflector挖掘.NET 2.0配置源代码时,我只遇到了这个小宝石,这是一个很棒的小工具.每个配置部分在由.NET配置类解析和加载时都会分配一个
SectionInformation对象.该SectionInformation对象包含有关配置节的元信息,并允许对子节配置文件(ASP.NET)中定义的节如何重写时进行一些管理.目前,我们将忽略SectionInformation提供的大部分内容,保存ConfigSource属性.通过向configSourceany的根元素添加属性ConfigurationSection,您可以指定将从中加载配置设置的备用外部源.在上面的配置文件中,该
部分来自一个名为的文件externalConfig/connectionStrings.config.将从指定的文件加载所有应用程序的连接字符串.现在连接字符串是从外部资源加载的connectionStrings.config,在相同的相对位置的每个环境中创建文件是相对简单的事情.因此,externalConfig/部分connectionStrings.config路径.这里的美妙之处在于我们可以为每个环境正确定义连接字符串一次.在配置文件未正确合并或根本未合并的部署期间,我们不必担心会意外覆盖这些设置.将应用程序中的更改部署到生产环境时,这可能是一个巨大的好处,因为存在正确的数据库连接字符串至关重要.使用该configSource属性的缺点是它需要将所有配置设置放在外部文件中.没有继承或覆盖是可能的,这在某些情况下会使它变得无用.与configSource属性一起使用的所有外部配置文件也必须位于main的相对子路径中.config文件.我相信这是关于将文件存储在Web环境中的相对父路径中的安全问题.需要注意的是,该
部分有一个更好的替代方法configSource,称为文件.如果您将文件属性而不是configSource与该部分一起使用,则可以在根.config文件和引用文件中定义设置..config也可以在引用的文件中覆盖根文件中的设置,只需添加具有相同键的内容即可.遗憾的是,file属性仅在该部分可用,并未构建到配置框架中.可以在您自己的配置节中实现类似的属性.在几个必备的分期付款之后,将在以后的高级配置主题中讨论这个问题;).
京公网安备 11010802040832号 | 京ICP备19059560号-6 