我需要在配置文件中存储一些设置(连接字符串、文件夹路径)。
我应该使用 App.config 吗?
看起来很明显,但是......
1)应用程序。包含一些我不希望任何人能够接触到的 .NET 配置内容(包、版本等)——我宁愿总是将这些内容编译到程序中。
2)将我的开发模式配置设置编译到程序中并在缺少 App.Config 时调用(默认为内置资源或其他东西)感觉很奇怪
3)我喜欢干净的配置文件,这样我一眼就能看出设置是什么(而且我有强迫症)?
是的,把它全部塞进app.config
. 我的理由是,最终用户无法真正app.config
编辑其中的任何内容,即使是只有最终用户才知道的那些位(连接字符串和文件夹路径)。您想要一个不懂计算机的人用记事本编辑 XML 文件吗?我知道我没有。
获取最终用户值的唯一可靠方法app.config
是在安装过程中提示用户输入它们,然后自己将它们编写为自定义操作。
我对 *.config 文件的规则是在我希望能够在不重新部署二进制文件的情况下更改设置时使用它们。如果我不关心需要部署来进行更改,那么我将使用常量。如果我有疑问,我将使用配置文件。我几乎总是使用配置文件。
当我确实将 *.config 用于某事时,我将通过另一个“配置”类公开这些值,该类对我希望公开的每个值都有一个静态只读属性。即,如果我的应用配置有设置
<add key="ServerLoadTime" value="-30" />
然后我的配置类可能如下所示:
public static class Configuration
{
/// <summary>
/// Get the number of minutes before prior to the event that the server is started.
/// </summary>
public static int ServerLoadTime
{
get
{
if (ConfigurationManager.AppSettings["ServerLoadTime"] != null)
return int.Parse(ConfigurationManager.AppSettings["ServerLoadTime"]);
Logging.Write("ServerLoadTime is missing from the Configuration file.", EventLogEntryType.Warning, Logging.Sources.General, "Configuration.ServerLoadTime", null);
return -30; // return a default value.
}
}
}
这种方法创建了一个标准化的封装,它提供:
是的,这是最佳实践,并且可以防止人们不得不重新编译您的应用程序来进行基本的配置更改:例如。新用户需要收到一封自动电子邮件,更改配置文件比重新编译和重新部署应用程序要容易得多。关于您的配置文件问题,这是一个优雅的解决方案:http ://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx
我更喜欢只重命名文件,或者保留注释字符串,具体取决于我从开发到生产需要做多少。