自定义配置文件
本文关键字:配置文件 自定义 | 更新日期: 2023-09-27 18:16:23
我正在做研究,以便为当前使用ini文件进行配置设置的程序构建概念验证。正在考虑此更改,因为当前ini文件存储在程序的安装目录中。概念的证明是将ini文件迁移到用户配置文件中。
这个迁移本身不会是一个问题,但是我们支持的平台也将迁移到Windows 7。当前系统使用Windows XP,并使用写保护系统来避免对系统进行更改。我担心的是,用户配置文件在Windows 7的默认位置将被放置在一个文件夹,将写保护。这意味着如果用户必须重新启动系统(考虑到使用该系统的上下文中不太可能),那么对配置文件的最新更改将丢失。
我目前的想法是在我们移动其他用户创建文件的同一目录中创建一个自定义用户配置文件。这将允许我们告诉系统配置管理器允许更改哪些目录。
我发现了以下问题:如何写入主执行's .config userSettings节?
我唯一的问题是基于参考问题的可接受答案,我是否能够加载自定义配置文件,并轻松访问配置文件的属性(这是在参考System.Properties.Default.SomeApplicationSettingName) ?
我唯一担心的是用户配置文件的默认位置对于计算机新手来说很难找到。由于唯一容易找到的. net配置文件(默认情况下)位于与可执行文件相同的目录中,因此给定用户修改该文件的能力将受到质疑。
因为这是一个概念证明,我有能力使用。net Framework 4.0解决方案。不能取消的一个需求是使用外部第三方库。
考虑使用用户设置。您可以适当地读,写,修改它们并且它们被保存在具有写权限的正确位置
如果你只是在寻找用户设置和应用程序设置,这已经内置到。net框架中。
使用c#中的设置
配置设置和文件系统访问权限/安全性是完全不同的两件事。有一个配置文件不会影响你在上一个声明中所说的"引入不可接受的问题",如果文件夹或共享没有正确设置,这将是一个网络管理问题。你还可以在c#中使用传统的。ini文件我之前做过很多次但这违背了使用app.config文件的目的
我不是故意无礼的。但是,您真的熟悉使用.config文件所能实现的奇迹/魔力吗?您不应该担心找到.config文件的位置,因为您在开发/调试/编码期间使用的app.config文件与应用程序将引用/使用的实际文件不同。记住这一点