我以为这应该是一个配置文件,但找不到它。 谢谢。
整个配置文件的位置可能有些棘手。根据其是“用户”设置还是“应用程序”设置,它将进入不同的文件。有些设置甚至可以来自您的“机器”配置(如ASP.NET的情况)。而不是猜测一切的位置,我发现向.NET询问它在哪里查找这些文件更加有用。大致上:
//Machine Configuration Path
string path1 = ConfigurationManager.OpenMachineConfiguration().FilePath;
//Application Configuration Path
string path2 = ConfigurationManager.OpenExeConfiguration(
ConfigurationUserLevel.None).FilePath;
//User Configuration Path
string path3 = ConfigurationManager.OpenExeConfiguration(
ConfigurationUserLevel.PerUserRoamingAndLocal).FilePath;
这是添加到您项目中的内容。构建过程会将其命名为[myproject].exe.config。这个文件包含(大部分都是)只读的应用程序设置和用户特定设置的应用级默认值。应用程序级别的设置很难通过编程方式更改它们的值。应用程序级别的设置属性只有“get”定义。设计目的是:如果您的设置适用于应用程序的所有用户,则手动编辑(或安装程序)应该设置它们。如果它是每个用户不同的设置,则应将其设置为每个用户的设置。
如果没有[myproject].exe.config文件,您的应用程序将继续运行。为了实现这一点,二进制文件有其自己版本的文件“存储”。这在某些方面很有用,但也可能会引起混淆。如果您的.config文件放错了位置或者名称错误,.NET会恢复到“二进制默认设置”。这可能导致似乎无法通过更改配置文件来影响设置。使用上述方法可以知道.config文件真正的位置,否则将面临二进制默认设置的限制。
当您第一次使用“per-user”设置保存您的Default.Settings对象时,将生成此文件。该文件保存在用户文件夹路径下的位置,这个位置基于您项目的名称、版本、操作系统和其他一些黑暗的.NET魔法。这些设置的属性是可读/可写的。它们被设计成易于设置,并通过单个调用保存。
那么我的设置去哪里了?答案是:有许多文件可能会组合在一起形成“活动集”设置。App.config和user.config设置是基本块,但还有machine.config设置,还有可能会进一步复杂化事情的依赖程序集设置......但这是另一个话题了。
配置文件的真正实现散落在许多丑陋的情况和细节中。然而,只要了解它们如何组合在一起,它就是一个非常有用的系统。特别是当您意识到可以将这些设置数据绑定时 ;)
C:\Documents and Settings\username\Local Settings\Application Data
http://dotnetproject.blogspot.com/2006/08/where-is-userconfig-file-located-in.html