• 我们可以使用App.config;但它仅支持键/值对。
• 我们可以使用.Net配置中的"配置"部分；但这可能真的很复杂。
• 我们可以自己使用Xml序列化/反序列化。上课方式。
• 我们可以使用其他方法。他们会是什么？ ...

我们更喜欢使用其中一种或者其他方法(如果有)？为什么？

解决方案

如果可以解决，我将只使用App.Config，但是，如果我需要更复杂的东西，则将使用自定义配置部分。是的，一开始就很难理解，但是在我看来，一个统一的配置源以及对所有设置熟悉的配置值得花时间投资。

我将大部分配置保留在IoC容器中，例如Spring.Net。

我使用一个自定义的xml配置文件，其中每个环境使用不同的配置文件(dev / qa / prod)。配置文件是模板，可以使用服务的主机/端口配置等进行动态实例化，这使得多环境和故障转移非常容易，因为可以通过模板实例化代码进行处理。

当然，如果配置很少，并且不关心多个环境，则app.config更为标准，可能是最好的选择。

我发现NameValueCollectionHandler最简单，最好，并且通常会通过configSource属性链接到外部配置文件。

我尝试将ABSOLUTE MINIMUM配置放到配置文件中，其中大多数配置都使用对自己的部署环境具有自我意识的应用程序(例如，通过计算机名或者IP地址，如果知道)在代码中进行配置。当然，这需要对环境进行更多的预计划和了解，而在部署时则要少得多。

我过去是网络/系统管理员，现在我为数据库应用程序开发内部实用程序。我发现的是：

简单的非嵌套配置文件最适合那些不会改变其访问资源位置的应用程序。

任何更复杂的需求都需要通过管理UI进入数据库。这仅适用于常规业务用户。如果我们担心数据库损坏，请使用复杂的配置文件方法。文件损坏的程度往往少于数据库。

现在，如果用户是其他开发人员，那么我们将在使用什么存储配置时拥有更大的灵活性。

如果我们有.NET 3.0，我会发现XamlReader / XamlWriter非常便于存储设置。在以下情况下，他们可以向XAML写入/读取任何.NET对象：

• 该对象具有无参数构造函数
• 读取/写入的属性具有公共获取器和设置器

不必用任何属性装饰设置对象，这特别好。

当键值对不够用时，我将使用配置部分，因为它们使用起来并不复杂(除非我们需要一个复杂的部分)：

定义自定义部分：

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;

当app.config不再削减它时，dataset.WriteXML()/ dataset.ReadXML()对我来说效果很好。

将配置放入数据库中。如果我们在多台机器上运行应用程序(例如，客户端服务器应用程序)，则所有每台机器的配置系统都是PITA。单个配置区域是放置配置的最佳方法。写一个GUI来管理它，你会很高兴。

将app.config文件推出到200个客户端盒中。这并不有趣，尤其是当一个人被错过时(相信他们，他们确实如此)。

通常，我更喜欢使用自定义xml文件和Xml序列化方法来读取和写入此配置文件...不限于键/值对，实现起来也不复杂...

我很幸运滚动自己的特殊类，该类从与调用程序集关联的" .settings"文件返回配置数据。该文件是XML，而settings类则将其公开公开为XDocument。此外，此设置类的索引器从/ settings / setting节点返回元素值。

对于仅需要键/值对访问设置的简单应用程序非常有用，对于需要定义自己的结构并使用System.Xml.Linq查询XML文档的复杂设置非常有用。

自己滚动的另一个好处是，当文件在运行时更改时，可以使用FileSystemWatcher和callback Action类型自动触发方法。

我认为键/值配置对于简单的配置文件非常有效。当文件开始增长且难以维护时，这成为一个问题。我们开始将配置文件拆分为"通用"和"特定"应用程序配置。文件访问对应用程序是透明的，在大多数情况下，"公用"值相同，但对于每个已部署的应用程序，"特定"值均不同。

我使用自定义的xml配置文件。每个设置都有一个键，值和类型。

它的一个主要部分包含所有设置，其他部分包含特定环境(开发，暂存，实时)的设置替代。部署时，我不需要替换文件的各个部分。
我有一个小的包装器，我们可以调用该包装器以获得特定的设置或者包含所有设置的字典。

我最近创建了一个T4模板，该模板将读取配置文件并创建一个静态的强类型设置类。那是一个巨大的节省时间。