获取配置的路径
事实证明这一点非常简单：
你只需使用这样的东西：
public string FileLocation
{
get { return Configuration.FilePath; }
}
private static Configuration Configuration
{
get { return OpenConfig(ConfigurationUserLevel.PerUserRoamingAndLocal); }
}
private static Configuration OpenConfig(ConfigurationUserLevel userLevel)
{
return ConfigurationManager.OpenExeConfiguration(userLevel);
}
那里传递的枚举还有另外两个值： None 似乎指向 app.config 所在的位置，而 PerUserRoaming 似乎总是指向不存在的地方。我无法找到有关何时适合使用此功能的更多详细信息，但就我而言，似乎不适合。
正如上面刚刚提到的，此调用的一个令人困惑的事情是它将返回文件的路径是否应该被保存/存在。这意味着该文件通常不存在！ ConfigurationManager和Settings（从ApplicationSettingsBase派生的自动生成的类）之间不明确的关系给我带来了很大的痛苦！
保存空白配置
一些障碍如下：
如果你添加一个settings.Settings类，这也会添加一个app.config。除非您将其与安装的程序一起提供，否则您将看到程序的安装版本和开发版本之间的不同行为 - 一个将使用 app.config 中的值创建设置文件，而另一个则不会。对我来说最简单的解决方案是完全删除 app.config。
我试图在配置上使用 save 方法，它允许您指定保存所有属性（无论默认值如何），并允许您指定保存，即使配置尚未修改。然而，在设置了两个标志的情况下调用此方法不会执行任何操作 - 看来您在设计器中以某种方式创建的设置在设置之前并不真实 - Configuration 和 ConfigurationManager 是较旧的处理方式，而 ApplicationSettingsBase 可能使用其中之一或两者其中他们不能很好地整合。
更令人困惑的是，如果您查询设置，那么它们将具有值（对于字符串，它们将具有“”）。但是，如果您保存设置，那么这些设置不会保存到文件中指定的位置！事实上根本不会创建任何文件！尽管如果您有 app.config，但如果您使用上面的强制保存方法，则会创建一个文件，因为默认值是在 app.config 中指定的！
解决方案似乎是检查每个属性中的默认值，然后设置默认值。这看起来应该是一个无操作，但 getter 并不遵循“如果我没有设置，我将在查询时创建它”的逻辑，而是假装存在一个具有默认值的设置。设置任何值似乎实际上都会创建该设置。
var somethingUnSet = _settings.Something == "";
if (somethingUnset)
_settings.Something = "";
if(somethingUnset|| somethingElseUnset)
{
_settings.Save();
ExitWithError("config needs setting up at " + _settings.FileLocation);
return;
}
最后，这给了我想要的结果 - 文件被保存在配置管理器指定的位置，其中包含需要填写的空属性。认为 UI 会更快！
我使用包装的 Settings 对象来方便地更改测试中的值，而无需处理单例。这还有一个很好的副作用，您可以添加额外的代码（例如文件位置），而不必担心在添加更多设置时代码生成会覆盖内容。
