Доступность типа C # - использование архитектуры параметров приложения в приложениях - строго типизированная конфигурация - PullRequest
Новая
       12

Доступность типа C # - использование архитектуры параметров приложения в приложениях - строго типизированная конфигурация

1 голос
/ 04 декабря 2010

Я ищу написать унифицированный класс конфигурации, который объединяет настройки в нескольких приложениях, которые существуют из Архитектуры настроек приложений (ASA) Visual Studio.(http://msdn.microsoft.com/en-us/library/8eyb2ct1.aspx)

ASA генерирует класс Settings.Designer.cs для каждого проекта. Я хотел бы объединить все классы настроек нескольких проектов, чтобы они были доступны из одного класса. Например, у меня естьпроект, который используется только для хранения общих настроек, и все. Этот проект имеет класс вроде: 

public static class ConfigManager
{
 public static TopNamespace.Configuration.Properties.Settings Shared
 {
  get { return TopNamespace.Configuration.Properties.Settings.Default; }
 }
}

Это позволяет мне получить доступ к конфигурации, например: 

ConfigManager.Shared.ConfigKey

Что бы ямне нравится расширять этот класс ConfigManager, чтобы дать мне доступ к сгенерированным классам настроек других проектов. Я не уверен, возможно ли это или как это сделать. Например, я хотел бы иметь возможность сделать:

ConfigManager.ApplicationName.ConfigKey

ConfigManager.OtherApplicationName.ConfigKey

Циркулярные ссылки не позволяют мне добавлять ссылки на проекты приложений из проекта конфигурации, чтобы получить доступ к типам, чтобы сделать больше членов, таких как: 

public static class ConfigManager
{
 public static TopNamespace.Configuration.Properties.Settings ApplicationName
 {
  get { return TopNamespace.ApplicationName.Properties.Settings.Default; }
 }
 public static TopNamespace.Configuration.Properties.Settings OtherApplicationName
 {
  get { return TopNamespace.OtherApplicationName.Properties.Settings.Default; }
 }
}

И затем пытаться добавитьссылка на проект конфигурации обратно из проектов приложения, чтобы получить доступ к классу ConfigManager.

Я думал орасширение классов, но частичные классы не будут работать между сборками, и вы не можете наследовать от статических классов.Использование дженериков не похоже на то, что это было бы очень хорошим решением, поскольку у вас не могло бы быть хорошего чистого типа подписей ConfigManager.ApplicationName.SettingName для членов свойства.

Есть ли способ использовать наследование или провести динамический анализ доступных типов в Домене приложений и загрузить типы настроек для доступных приложений, которые будут доступны из одного класса ConfigManager?Предоставление доступа ко всем классам настроек для нескольких проектов, сгенерированных Visual Studio, из одного класса менеджера со свойствами для каждого экземпляра настроек проекта.

1 Ответ

1 голос
/ 09 декабря 2010

Я окончательно остановился на настройке этого метода, используя класс, который был «статическим», но не определялся таким образом, потому что .Net не позволяет вам наследовать статические типы.Но вы можете написать класс со всеми статическими членами и использовать защищенный конструктор, что делает его статическим для всех целей и задач.Затем вы можете наследовать от своего внешнего класса проекта, например: 

public class ConfigManager : ExternalProjectNamespace.ConfigManager

Используя это соглашение, я смог получить нужный синтаксис без необходимости дублировать код в каждом отдельном проекте, который будет использовать ConfigManager.

...