这个问题是前一阶段写windows服务碰到的。本来在写获取配置文件的某个配置的值的时候,通常我都是写类似下面的这么一个静态方法来获取:
1: /// <summary>
2: /// 获取每次处理记录数
3: /// </summary>
4: /// <returns></returns>
5: private static int GetRecordCount()
6: {
7: int recordCount = 10000;
8: try
9: {
10: recordCount = Math.Abs(int.Parse(ConfigurationManager.AppSettings["RecordCount"]));
11: if (recordCount==0)
12: {
13: recordCount = 10000;
14: }
15: }
16: catch
17: {
18: recordCount = 10000;
19: }
20: return recordCount;
21: }
RecordCount表示每次从数据库读取的记录数。在服务写好安装后测试的时候,这个参数改过好几次,起初它的默认值是10000,后来分别改过为500,100,50和10。可是改完之后我不得不重启服务才能让配置文件起作用。经过几次这种折腾之后,感觉体验太差了。上网一搜,找到了这一篇:Do you have to restart a windows service if you change the app.config? 在原问题中,一个哥们给出了解答,就是通过ConfigurationManager.RefreshSection刷新某一配置节点,我们获取配置值的时候就不需要重启服务了:
- /// <summary>
- /// 获取每次处理记录数
- /// </summary>
- /// <returns></returns>
- private static int GetRecordCount()
- {
- int recordCount = 10000;
- try
- {
- ConfigurationManager.RefreshSection("appSettings");// 刷新命名节,在下次检索它时将从磁盘重新读取它。
- recordCount = Math.Abs(int.Parse(ConfigurationManager.AppSettings["RecordCount"]));
- if (recordCount == 0)
- {
- recordCount = 10000;
- }
- }
- catch
- {
- recordCount = 10000;
- }
- return recordCount;
- }
经过测试,确实如此。
你可能会问,为什么加了那一行ConfigurationManager.RefreshSection(命名节点);就可以了呢?
查看MSDN,解释是这样的:“刷新命名节,这样在下次检索它时将从磁盘重新读取”。下面是VS里的函数说明:
- //
- // 摘要:
- // 刷新命名节,这样在下次检索它时将从磁盘重新读取它。
- //
- // 参数:
- // sectionName:
- // 要刷新的节的配置节名称或配置路径和节名称。
- public static void RefreshSection(string sectionName);
原来,更改配置文件之后,应用程序读取配置的顺序不是从物理文件读取,而是从其缓存中读取(ConfigurationManager.RefreshSection方法在不影响其他节的前提下使指定配置节的缓存失效),必须强制刷新配置文件,才能读取到更改后的配置节信息 。
毫无疑问,和正常的读取配置文件节点方法相比,这个读取配置的方法在性能上应该有点影响,至于损失多少,会不会造成性能瓶颈,你懂的。
最后,从MSDN的例子我们也可以看出来,这个方法对于动态写入/读取配置文件非常有效。不过对于web应用程序这个方法可能不适合,因为大家知道,修改web.config相当于重启了web应用程序。