我真的对.Net v2中dll的.Net配置，ASP.net网站等的各种配置选项感到困惑，尤其是考虑到配置文件在链的UI /最终用户端的影响时。

因此，例如，我使用的某些应用程序使用我们可以通过其访问的设置：

string blah = AppLib.Properties.Settings.Default.TemplatePath;

现在，此选项似乎很酷，因为成员是用打字方式键入的，而我将无法键入Visual Studio 2005 IDE中不存在的属性名称。我们在命令行可执行项目的App.Config中以如下代码结束：

<connectionStrings>
    <add name="AppConnectionString" connectionString="XXXX" />
    <add name="AppLib.Properties.Settings.AppConnectionString" connectionString="XXXX" />
</connectionStrings>

(如果我们没有第二个设置，则有人向实时框发布调试dll可能已经在其中嵌入了调试连接字符串eek了)

我们还可以通过以下方式访问设置：

string blah = System.Configuration.ConfigurationManager.AppSettings["TemplatePath_PDF"];

现在，这些看起来很酷，因为我们可以从dll代码或者exe / aspx代码访问设置，并且在Web或者App.config中需要的是：

<appSettings>
   <add key="TemplatePath_PDF" value="xxx"/>
</appSettings>

但是，当然可能未在配置文件中设置该值，或者字符串名称可能输入有误，所以我们遇到了另一组问题。

所以...如果我的理解是正确的，则前一种方法会提供强类型输入，但dll与其他项目之间的值共享很差。后者提供了更好的共享，但打字却较弱。

我觉得我一定很想念东西。目前，我什至不关心应用程序能够将值写回配置文件，加密或者类似的东西。另外，我已经决定，存储任何非连接字符串的最佳方法是在数据库中...，然后我要做的第二件事是在数据库连接出现问题的情况下，将电话号码存储给文本人员，因此它们必须存储在DB外部！

解决方案

回答

我认为困惑来自于这样一个事实，即第一个示例似乎是一个自制的库，而不是.NET的一部分。
configurationmanager示例是内置功能的示例。

回答

如果在VS 2005+中使用设置选项卡，则可以添加强类型设置并获得智能感知，例如在第一个示例中。

string phoneNum = Properties.Settings.Default.EmergencyPhoneNumber;

这实际上存储在App.Config中。

我们仍然可以使用配置文件的appSettings元素，甚至滚动自己的ConfigurationElementCollection，ConfigurationElement和ConfigurationSection子类。

在非连接字符串的情况下，关于存储设置，数据库或者配置文件的位置：这取决于应用程序体系结构。如果我们拥有由所有客户端共享的应用程序服务器，请在应用程序服务器上的App.Config中使用上述方法。否则，我们可能必须使用数据库。将其放在每个客户端的App.Config中会引起版本控制/部署麻烦。

回答

我支持Rob Grays的答案，但想稍加补充。这可能太明显了，但是如果我们使用多个客户端，则app.config应该存储特定于安装的所有设置，而数据库应该存储几乎所有其他内容。

单个客户端(或者服务器)应用程序有所不同。这实际上是更多个人选择。值得注意的例外是，如果设置是数据库中记录的ID，在这种情况下，我将始终使用外键将设置存储在数据库中，以确保不会删除引用。

回答

是的，我想我/我们正处在令人头疼的境地，Rob认为我们在需要访问同一数据库的三台独立服务器上拥有5个或者6个不同的网站和应用程序。就目前情况而言，每个人都有自己的Web或者App.config，其中包含描述的设置和/或者我们的主要DB-access dll库中的替代设置。

Rob，当我们说应用程序服务器时，我不确定意思吗？我能想到的最近一点是，我们至少可以通过将它们放置在目录层次结构中更高的web.config中，在同一台计算机上的站点之间共享一些设置...但这也不是我能够研究的……以为更重要的是要了解哪种强或者弱类型的路线"更好"。

回答

Nij，我们的思维差异来自于不同的观点。我正在考虑开发主要使用WinForms客户端的企业应用程序。在这种情况下，业务逻辑包含在应用程序服务器上。每个客户端都需要知道要拨打的电话号码，但是如果该电话号码发生更改，则将其放置在每个客户端的App.config中会带来问题。在那种情况下，将应用程序配置信息(或者应用程序范围的设置)存储在数据库中并让每个客户端从那里读取设置似乎是显而易见的。

另一种.NET方式(我之所以有所不同，是因为在.NET以前，我们已经在DB表中存储了应用程序设置)是将应用程序设置存储在app.config文件中，并通过生成的Settings类进行访问。

我离题了。情况听起来有所不同。如果所有不同的应用程序都位于同一服务器上，则可以将设置放在更高级别的web.config中。但是，如果不是这样，我们还可以拥有一个单独的"配置服务"，所有这三个应用程序都可以通过对话来获取它们的共享设置。至少在此解决方案中，我们不会在三个地方复制代码，从而增加了在添加设置时出现维护问题的可能性。虽然听起来有点过分设计。

我个人的喜好是使用强类型设置。实际上，我是根据数据库中的设置表生成自己的强类型设置类的。这样我就可以兼得两全其美。智能感知我的设置和存储在数据库中的设置(注意：这是在没有应用程序服务器的情况下)。

我也有兴趣学习其他人的策略：)