2011-12-02 153 views
-1

我正在做研究,以便为当前使用ini文件进行配置设置的程序构建概念验证。正在考虑这种改变,因为目前ini文件存储在程序的安装目录中。概念证明是将ini文件迁移到用户配置文件中。自定义配置文件

仅此迁移将不会成为问题,但我们支持的平台也将迁移到Windows 7系统当前使用Windows XP和使用一个写保护系统,以避免对系统的更改。我担心的是,Windows 7默认位置中的用户配置文件将被放置在一个将被写保护的文件夹中。这意味着如果用户不得不重新启动系统(不太可能考虑到系统甚至被使用的情况),那么对配置文件的最新更改将会丢失。

我现在的想法是建立在同一个目录中的自定义用户配置文件,我们正在其他用户创建的文件。这将允许我们告诉系统配置管理器哪些目录允许改变。

我发现以下问题:How to write to the main exe's .config userSettings section?

我基于基准问题的接受的答案唯一的问题,我就可以加载自定义配置文件,方便地访问使用属性(这是参考System.Properties.Default.SomeApplicationSettingName)的配置文件?

我关心的唯一的事情是,用户配置文件的默认位置是很难由一个新手计算机用户定位。由于唯一容易找到的.NET配置文件位于(默认情况下)与可执行文件位于同一目录中,因此给定用户修改该文件的能力将受到质疑。

由于这是概念上的我一定要使用的.NET Framework 4.0解决方案的能力证明。无法解除的一个要求是使用外部第三方库。

+0

为什么用户需要找到他们的配置文件?应用程序不应该为他们处理? – jrummell

回答

1

考虑使用User settings。你可以读,写,适当地修改它们,它们被保存在具有写权限

0

配置设置和文件系统的访问权限/安全性是完全2个不同的东西的正确位置。如果文件夹或共享没有正确设置,那么拥有配置文件不会影响您在上次声明中提到的有关“引入不可接受的问题”的内容,这将成为网络管理员问题。你也仍然可以使用C#常规.ini文件之前,很多很多次我都做了,但来击败具有app.config文件

我的意思并不是要健全粗鲁的目的..但你真正熟悉你可以用.config文件做的奇迹/魔法..?您不必担心查找.config文件的位置,您在开发/调试/编码过程中使用的app.config文件与应用程序将引用/使用的实际文件不同。请牢记这一点