按照 CodeProject 和 StackOverflow.105932 （以及其他一些内容，例如 StackOverflow.1873658 和MSDN文章）我有一个主要表单，其大小，位置和WindowState保存在Properties.Settings.Default.<name>中，并从Properties.Settings.Default.WindowState = WindowState;读取，例如Properties.Settings[this.ToString()].WindowState = WindowState;，这对于这一个表单非常有用。我发现的每个代码示例似乎都认为WindowState只有一个全局设置，没有人说如何区分每个实例的这些设置。
但是，我在Form的超类中编写了代码，因为我希望此类应用程序中的所有Forms都继承自该类，因此它们都能够保存/读取自己的大小，位置和状态。
我想要做的只是将上面的密钥路径中的“Default”替换为继承表单的类名。这是伪代码，如果它有效，它会很棒（它没有，我找不到一个变体）：
{{1}}
我如何正确，可重复使用，可维护，防熵？
编辑：“配置部分”会是答案吗？ （也许为每个Form子类创建一个部分？）
编辑：不，不是配置部分，但我认为this class必须是正确解决方案的一部分。
答案 0 :(得分：2)
嗯，其核心不是默认情况下设置在.NET中的工作方式。使用Scope = User进行设置的设置文件会被隐藏在具有不可言名的私有AppData文件夹中。通过散列主EXE的各种属性创建的名称，包括其名称，位置和[AssemblyVersion]。重要的是防止程序意外覆盖彼此的设置文件。没有记录的方法从另一个程序获取该文件。主要是因为你没有好的方法来猜测另一个程序的这些属性值。
有一些解决方法，您可以创建自己的从SettingsProvider派生的类，而不是默认的LocalFileSettingsProvider类。这有点痛苦，System.Configuration并不是.NET中最好的命名空间。入门的好方法是使用RegistrySettingsProvider SDK sample。
或者只是解决问题，只需创建自己的XML文件，存储在AppData文件夹中，您可以随时从任何应用程序获取该文件。这通常是一个好主意，因为当许多应用程序共享一个公共数据文件时，你会受到版本问题的影响。您需要在其自己的程序集中声明一个XML可序列化的类，以存储这些属性。带着沉重的“不要先跟我说话就改变”的评论。