C# 自定义配置文件

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

这种迁移本身不会引起关注，但我们支持的平台也将迁移到Windows7。当前系统使用Windows XP并使用写保护系统来避免对系统进行更改。我担心的是，Windows 7上默认位置的用户配置文件将被放置在一个写保护的文件夹中。这意味着，如果用户必须重新启动系统（考虑到使用该系统的上下文，这不太可能），则配置文件的最新更改将丢失

我目前的想法是在我们将其他用户创建文件移动到的同一目录中创建自定义用户配置文件。这将允许我们告诉系统配置管理器允许更改哪些目录

我发现了以下问题：

根据参考问题的公认答案，我唯一的问题是，我是否能够加载自定义配置文件，并轻松访问配置文件的属性（这是对System.Properties.Default.SomeApplicationSettingName的引用）

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

---

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

如果您只是查找用户设置与应用程序设置，则这已经内置到.NET Framework中

---

考虑使用。您可以适当地读取、写入和修改它们，并将它们保存在具有写入权限的正确位置

配置设置和文件系统访问权限/安全性是两件完全不同的事情。拥有一个配置文件不会影响您在上一次声明中关于“引入不可接受的问题”的陈述，如果文件夹或共享未正确设置，这将是一个网络管理问题。此外，您还可以在C中使用传统的.INI文件，我以前已经使用过很多次了，但这与使用app.config文件的目的背道而驰

---

我不想听起来粗鲁。。但是，您真的熟悉使用.config文件可以实现的奇迹/魔力吗。。？您不必担心找到.config文件的位置，而且在开发/调试/编码期间使用的app.config文件与应用程序将引用/使用的实际文件不同。请记住这一点

为什么用户需要找到他们的配置文件？应用程序不应该为他们处理这些吗？