今天重构了一下代码之后,再次运行程序发现App.config中的配置项怎么都读不到了。配置文件的读取部分我直接使用了Settings,这部分没有做任何修改的,理论上不应该出现读取的问题。回忆了一下我做重构的过程,在这次运行失败之前我做的最近的一次修改仅仅是重新设置了一下项目的默认名字空间。难道说Settnigs读取配置文件还跟名字空间有关?总觉得MS不会做的这么傻……
暂时不想理会它了,先验证我的功能性的代码有没有问题吧。于是乎我在设计界面将Setting中值修改成了我需要值,然后保存。意外地,我发现VS又给我重新生成了一次配置文件(App.config里的****.Settings节点)。不是修改原来的Settings的section中的xml,而是重新生成了一个新的section,而新section的名字中出现了我刚刚修改的名字空间。对照一下看会比较清楚:
<CDSConverter2To3.Settings>
<!-- the original mc data folder which contains the old GameSet,Template,cds-mc.ptd-->
<setting name="SourceMCDataFolder" serializeAs="String">
<value>C:\MC-Data</value>
</setting>
<CDS.V3.Converter.Settings>
<!-- the original mc data folder which contains the old GameSet,Template,cds-mc.ptd-->
<setting name="SourceMCDataFolder" serializeAs="String">
<value>C:\MC-Data</value>
</setting>
“Settings”之前的为名字空间。我的名字空间正好是从CDSConverter2To3变为CDS.V3.Converter,所以这里出现了这样的两个section。
名字空间+Settings类名其实就是Settings类的全名了。我猜测这个地方Settings读取xml配置文件的实现方式可能是简单的xml序列化,如果真是这样,当类的全名不正确的时候,从xml反序列化到类实例的操作就会失败,Settings会选择使用在设计时指定的默认值。这样的话,无论你怎么修改app.config的值,从Settings类获得的永远是设计时的值。