Ответ 1
Вы можете реализовать свой собственный класс настроек, наследуя ApplicationSettingsBase. В качестве хорошего начала вы можете добавить файл настроек пользователя по умолчанию в пример проекта (щелкните правой кнопкой мыши по проекту → Properties → Settings → This project does not contain a default settings file. Click here to create one.). Добавьте параметр пользовательского охвата и исследуйте структуру созданного конструктором файла Settings.Designer.cs:
namespace ConsoleApplication1.Properties {
[global::System.Runtime.CompilerServices.CompilerGeneratedAttribute()]
[global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.VisualStudio.Editors.SettingsDesigner.SettingsSingleFileGenerator", "11.0.0.0")]
internal sealed partial class Settings : global::System.Configuration.ApplicationSettingsBase {
private static Settings defaultInstance = ((Settings)(global::System.Configuration.ApplicationSettingsBase.Synchronized(new Settings())));
public static Settings Default {
get {
return defaultInstance;
}
}
[global::System.Configuration.UserScopedSettingAttribute()]
[global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
[global::System.Configuration.DefaultSettingValueAttribute("John Doe")]
public string Name {
get {
return ((string)(this["Name"]));
}
set {
this["Name"] = value;
}
}
}
}
В вашей пользовательской реализации вы не будете ограничиваться модификаторами доступа, создаваемыми разработчиками, поэтому вы можете реализовать класс Settings как внутренний с внутренними сеттерами, видимый только для необходимых сборок или любого, что подходит вашим потребностям.
Конечно, вы всегда можете реализовать свой собственный механизм serialize/deserialize, но вы потеряете функциональность, предоставляемую методами ApplicationSettingsBase Updgrade, Reload и Reset. Если вам не нужны какие-либо из них, это может быть более чистым подходом.