Какой способ настройки вы предпочитаете в .net? Зачем?

Ответ 1

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

Определите свой раздел:

        public class CustomSection : ConfigurationSection
        {
            [ConfigurationProperty("LastName", IsRequired = true,
            DefaultValue = "TEST")]
            public String LastName
            {
                get { return (String)base["LastName"]; }
                set { base["LastName"] = value; }
            }

            [ConfigurationProperty("FirstName", IsRequired = true, DefaultValue =
            "TEST")]
            public String FirstName
            {
                get { return (String)base["FirstName"]; }
                set { base["FirstName"] = value; }
            }

            public CustomSection()
            {

            }
        }

Программно создайте свой раздел (если он еще не существует):

           // Create a custom section.
            static void CreateSection()
            {
                try
                {

                    CustomSection customSection;

                    // Get the current configuration file.
                    System.Configuration.Configuration config = ConfigurationManager.OpenExeConfiguration(@"ConfigurationTest.exe");

                    // Create the section entry  
                    // in the <configSections> and the 
                    // related target section in <configuration>.
                    if (config.Sections["CustomSection"] == null)
                    {
                        customSection = new CustomSection();
                        config.Sections.Add("CustomSection", customSection);
                        customSection.SectionInformation.ForceSave = true;
                        config.Save(ConfigurationSaveMode.Full);
                    }
                }
                catch (ConfigurationErrorsException err)
                {
                    //manage exception - give feedback or whatever
                }

            }

Для вас будет создано следующее определение CustomSection и фактическое CustomSection:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="CustomSection" type="ConfigurationTest.CustomSection, ConfigurationTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" allowLocation="true" allowDefinition="Everywhere" allowExeDefinition="MachineToApplication" overrideModeDefault="Allow" restartOnExternalChanges="true" requirePermission="true" />
  </configSections>
  <CustomSection LastName="TEST" FirstName="TEST" />
</configuration>

Теперь извлеките свои свойства раздела:

    CustomSection section = (CustomSection)ConfigurationManager.GetSection("CustomSection");
    string lastName = section.LastName;
    string firstName = section.FirstName;

Ответ 2

Если мне это удастся, я просто использую App.Config, однако, если мне нужно что-то более сложное, я буду использовать настраиваемые разделы конфигурации. Да, это боль, чтобы понять вначале, но единый источник конфигурации и привычная конфигурация для всех настроек стоит времени на мое мнение.

Ответ 3

Поместите свою конфигурацию в базу данных. Если вы запускаете приложение на более чем 1 машине (например, клиент-серверное приложение), то все системы конфигурации каждой машины являются PITA. Единственная область конфигурации - лучший способ разместить вашу конфигурацию. Напишите gui, чтобы управлять им, и вы будете очень счастливы.

Перемещение файлов app.config на 200 клиентских ящиков. Это не забавно, особенно когда вас пропускают (и они это делают, поверьте).

Ответ 4

В прошлом я был администратором сети/системы, и теперь я разрабатываю внутренние утилиты для приложений баз данных. Я нашел следующее:

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

Все, что сложнее, нужно зайти в базу данных с пользовательским интерфейсом администрирования. Это относится только к обычным бизнес-пользователям. Если вас беспокоит повреждение базы данных, используйте подход к сложному конфигурационному файлу. Файлы, как правило, повреждают меньше, чем базы данных.

Теперь, если ваши пользователи - другие разработчики, у вас будет гораздо больше гибкости в том, что использовать для хранения ваших конфигураций.

Ответ 5

Я использую настраиваемый файл конфигурации xml, где для каждой среды используется другой файл конфигурации (dev/qa/prod). Конфигурационные файлы - это шаблоны, которые динамически создаются с помощью таких функций, как конфигурации хоста и порта для служб - это упрощает работу с несколькими средами и отказоустойчиво, поскольку он может обрабатываться кодом экземпляра шаблона.

Конечно, если у вас очень мало настроек и они не связаны с несколькими средами, то app.config является более стандартным и, вероятно, лучшим способом.

Ответ 6

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

Я пытаюсь установить конфигурацию ABSOLUTE MINIMUM в конфигурационных файлах, причем большинство из них настраивается в коде с помощью приложения, которое самоочевидно в своей среде развертывания (например, по имени машины или IP-адресу, если известно). Конечно, это потребовало гораздо большего предварительного планирования и знаний о вашей среде, но гораздо меньше головной боли при развертывании.

Ответ 7

Конфигурации клавиш/значений я работают очень хорошо для файлов простых конфигураций. Это становится проблемой, когда файл начинает расти и его трудно поддерживать. Мы начали разделять конфигурационный файл на "общие" и "конкретные" конфигурации приложений. Доступ к файлам прозрачен для приложения, "общие" значения в большинстве случаев одинаковы, но "конкретные" отличаются для каждого развернутого приложения.

Ответ 8

Я использую настраиваемый файл конфигурации xml. Каждый параметр имеет ключ, значение и тип.

В нем есть один основной раздел, содержащий все настройки и дополнительные разделы, содержащие переопределения настроек для определенных сред (dev, staging, live). Это не нужно заменять разделы файла при развертывании. У меня есть небольшая оболочка, которую вы можете вызвать, чтобы получить конкретную настройку или словарь, содержащий все из них.

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

Ответ 9

Я сохраняю большую часть своей конфигурации в контейнере IoC, например. Spring.Net.

Ответ 10

Если у вас есть .NET 3.0, я нахожу XamlReader/XamlWriter очень удобным для хранения настроек. Они могут писать/читать любой объект .NET в XAML, если:

• Объект имеет конструктор без параметров
• Свойства для чтения/записи имеют общедоступные получатели и сеттеры

Особенно приятно, что вам не нужно украшать ваши объекты настроек любыми атрибутами.

Ответ 11

dataset.WriteXML()/dataset.ReadXML() работает хорошо для меня, когда app.config больше не режет.

Ответ 12

В основном я предпочитаю использовать пользовательский XML файл и метод Xml Serialization для чтения и записи этих файлов конфигурации... Не ограничиваясь парами ключ/значение и не сложно реализовать...

Ответ 13

Мне повезло сменить собственный специальный класс, который возвращает данные конфигурации из файла ".settings", связанного с вызывающей сборкой. Файл представляет собой XML, и класс настроек предоставляет его публично как XDocument. Кроме того, индексщик для этого класса настроек возвращает значения элементов из /settings/settings.

Работает отлично для простых приложений, где вам просто нужен доступ к параметрам пары ключ/значение, и отлично подходит для сложных настроек, где вам нужно определить свою собственную структуру и использовать System.Xml.Linq для запроса XML-документа.

Еще одно преимущество вашей собственной загрузки заключается в том, что вы можете использовать FileSystemWatcher и callback Action type для автоматического запуска метода при изменении файла во время выполнения.