Совместное использование настроек между приложениями - PullRequest
Новая
       13

Совместное использование настроек между приложениями

11 голосов
/ 30 июля 2010

У меня есть несколько сборок .NET, все из которых должны иметь общие пользовательские настройки, такие как предпочтения, имена пользователей и т. Д. Одна - это приложение WPF, другая - консольное приложение, а третья - надстройка Office.Все эти настройки относятся к области действия пользователя.

Только приложение WPF должно иметь возможность изменять настройки.Остальные просто читают их.

В идеале я хотел бы использовать инфраструктуру конфигурации .NET.Я не уверен, как это сделать, хотя.Если я добавлю Настройки в приложение WPF, как другие приложения смогут найти файл user.config?

Не проще ли создать библиотеку классов, использовать IsolatedFileStorage и сериализовать мои настройки?

Буду признателен за любой совет.

Ответы [ 2 ]

2 голосов
/ 04 мая 2015

Вы можете реализовать свой класс пользовательских настроек, унаследовав 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 как внутренний с внутренними установщиками, видимыми только для необходимых сборок или для того, что соответствует вашим потребностям.

Конечно, вы всегда можете реализовать свой собственный механизм сериализации / десериализации, но вы потеряете функциональность, предоставляемую методами ApplicationSettingsBase Updgrade, Reload и Reset. Если вам не нужно ничего из этого, это может быть более чистый подход.

0 голосов
/ 02 мая 2015

Я бы порекомендовал вам создать сервис для предоставления и обновления информации о пользователях и / или предпочтениях. Это будет лучшая архитектура, более чистое решение, и его будет легче поддерживать и расширять.

...