.NET系统配置属性的加载层次结构是什么?

4
我有一个一般性的问题,但我也会解释为什么我在问,这样你就可以更好地理解我的意思。
我有一个dll,在设置中定义了一个webservice url,并且在运行时使用Settings.Default从设置中获取url。然而,我们的任何环境都没有(dllName).dll.config文件,调用应用程序的(exeName).exe.config也没有定义特定的设置。很明显默认值没有被使用,因为它被设置为某个内部IP地址; 然而,这在生产中有效,他们没有在任何.config文件中找到此设置,但它仍然以某种方式命中了正确的webservice URL。我需要知道在这种情况下该值是从哪里加载的。
所以我的更广泛的问题是,.net中如何加载设置的层次结构是如何工作的?例如,它首先查找machine.config,然后查找(exeName).exe.config,如果是dll,则会转到(dllName).dll.config吗?它首先在哪里查找,在其他位置中查找的顺序是什么,除了我没有提到的位置,还有其他地方可以定义此配置吗?
此外,对于一个DLL,如果您在设置中定义了某些内容,那么它是否作为默认值嵌入编译的dll中,并且如果在任何其他.config文件中找不到该属性,是否会使用该值?

1
类似于这样的内容 - http://msdn.microsoft.com/zh-cn/library/ms178685(v=vs.100).aspx? - t3hn00b
这是来自@t3hn00b的好链接。它应该是一个答案。 - Kamil
1个回答

7
.NET配置的层次结构提供了很高的灵活性,允许特定的用户或位置拥有自己的配置设置。但是,这些配置设置并不是孤立的,更具体水平上做出的重复设置可以覆盖在较不具体水平上做出的设置。如图所示,最具体的配置文件合并到不太具体的配置文件中,最具体的设置优先于最不具体的设置。在 Exe 上下文中,用户(或更准确地说是本地用户)设置最具体,其次是漫游用户(在两个或多个计算机之间共享),应用程序和最后是机器。

Config hierarchy and merging

我建议您阅读以下文章,因为您的答案只是引用:

有用的将是:


除非该图像和相关文本是您自己的,否则请给予适当的归属。 - wal
是的,我知道,评论仍然适用。这个答案只是从那篇文章中剪切/粘贴的。 - wal
@wal的回答是有参考资料的。当回答是MSDN文章或任何其他文章的一部分时,引用将足够好,特别是对于“广泛问题”。 - Regfor
如果您没有亲自输入这段文本,请引用它。 - wal
@wal 请仔细阅读。这是引用的,但文本上。我在这里忘记了引用标记,所以会添加一个。可以使用“引用”或“引述”的方式添加参考文献。 - Regfor

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接