我想检索appSettings键以读取文本文件。现在问题出在我的web.config文件中,其中有多个位置标签,并且在其中有多个appSettings标签,因此我的代码无法定位我实际需要的位置标签appSettings。
<location path="BidOnline">
<appSettings/>
<system.web>
<authorization>
<allow users="*"/>
<!-- Allow all users to the public location -->
</authorization>
</system.web>
</location>
<location path="Profdev/Public">
<appSettings/>
<system.web>
<authorization>
<allow users="*"/>
<!-- Allow all users to the public location -->
</authorization>
</system.web>
</location>
<location path="Punchout">
<system.webServer>
<httpProtocol>
<customHeaders>
<clear />
<add name="X-XSS-Protection" value="0"/>
</customHeaders>
</httpProtocol>
</system.webServer>
</location>
<!-- FACTS Service -->
<location path="Services/Facts">
<appSettings>
<!-- Disabeling the security should ONLY be done in test mode. -->
<add key="DisableSecurity" value="false"/>
<!--
The ip addresses listed below are the only address that can
be used while security is enabled (by default.) Any other
ip address attempting to post to the service will not be
able to.
-->
<add key="IPAddresses" value="63.84.95.4;162.40.107.4;207.5.114.131;216.69.96.174"/>
<!-- Set the ledger that the ar_text_mstr/dtl records will be setup with. -->
<add key="Ledger" value="GL"/>
</appSettings>
答案 0 :(得分:1)
location
属性包含请求的页面时,path
标记包含的值将覆盖其他web.config设置。在大多数情况下,我们不需要将appSettings
放在其中。最好将所有设置都放在顶级appSettings
元素中,然后仅将它们放在location
元素中,如果我们需要为特定路径内的页面覆盖它们。
在这种情况下,只有一个带有值的appSettings
元素,它位于此标记内:
<location path="Services/Facts">
<appSettings>
<add key="DisableSecurity" value="false"/>
<!-- other settings -->
</appSettings>
</location>
这意味着只有在请求的页面位于/ services / facts文件夹中时,这些设置才会“存在”。
如果需要任何页面可用的appSettings
元素,只需在configuration
元素中创建一个“上一级”:
<configuration>
<appSettings>
<add key="YourSetting" value="false"/>
<!-- other settings -->
</appSettings>
</configuration>
现在,无论您位于哪个页面(或应用程序的其他部分),都将始终可以访问它。
我认为appSettings
并没有太多用,尽管可能只是我一个人。我可以看到一些混乱的空间,因为许多开发人员会假设,如果有一个“根” appSettings
部分,则在应用程序运行时,这些值将永远不会改变,并且可能将它们存储在字符串中以供某些使用原因(尽管通常没有理由这样做。)他们可能没有意识到appSettings
标记内还有其他location
,并且他们读取的第一个值可能会被其他路径的其他页面重用。或者有人可以稍后添加location\appSettings
,但此操作将无效。
我猜得出的结论不是location\appSettings
不好,而是我们应该始终确保正在读取每个请求的设置,而不是将其存储在在请求之间可重用的变量中。
从技术上讲,web.config中显示的大多数appSettings
部分都没有关系,因为它们为空。
<appSettings/>