我正在尝试自定义user.config
文件的位置。目前,它存储了哈希和版本号
%AppData%\[CompanyName]\[ExeName]_Url_[some_hash]\[Version]\
我希望它对应用程序的版本不可知
%AppData%\[CompanyName]\[ProductName]\
可以这样做吗?有什么影响?升级后用户是否会丢失以前版本的设置?
答案 0 :(得分:76)
我希望将此引用的文字添加为我将来遇到此问题时的参考。据称,您可以通过调用Upgrade指示ApplicationSettings基础结构复制先前版本的设置:
Properties.Settings.Value.Upgrade();
来自Client Settings FAQ博文:(archive)
问:为什么user.config路径中有版本号?如果我部署新版本的应用程序,用户是否会丢失以前版本保存的所有设置?
答:有几个原因 user.config路径对版本敏感。(1)支持并行部署 不同版本的 应用程序(你可以这样做 例如,Clickonce)。它是 可能是不同版本的 应用程序有不同的设置 救了出来。
(2)升级时 应用程序,设置类可以 已被改变,可能不会 兼容所保存的内容, 这会导致问题。
但是,我们已经很容易了 从以前升级设置 该应用程序的版本 最新。只需致电 ApplicationSettingsBase.Upgrade()和 它将从中检索设置 以前的版本匹配 当前版本的类和商店 它们出现在当前版本中 user.config文件。你也有 覆盖此行为的选项 在您的设置类或中 您的提供商实施。
问:好的,但我怎么知道什么时候开始 致电升级?
答:好问题。在Clickonce中,何时 你安装了新版本的 application,ApplicationSettingsBase 将自动检测它 此时为您升级设置 设置已加载。在非Clickonce中 案例,没有自动升级 - 你必须自己打电话升级。 这是确定何时的一个想法 致电升级:
有一个名为的布尔值设置 CallUpgrade并给它一个默认值 价值为真。当您的应用启动时 起来,你可以这样做:
if (Properties.Settings.Value.CallUpgrade)
{
Properties.Settings.Value.Upgrade();
Properties.Settings.Value.CallUpgrade = false;
}
这将确保Upgrade() 只是第一次打电话 应用程序在新版本之后运行 已部署。
我不相信它能真正发挥作用 - 微软不可能提供这种能力,但方法也是如此。
答案 1 :(得分:36)
要回答第一个问题,从技术上讲,您可以将文件放在任何位置,但是您必须自己编写代码,因为文件的默认位置是您的两个示例中的第一个。 (link to how to do it yourself)
至于第二个问题,这取决于您部署应用程序的方式。如果通过.msi进行部署,则安装项目的属性中有两个哈希值(构建msi),“升级代码”和“产品代码”。这些决定了msi的安装方式,以及它是否可以升级,覆盖或安装在同一应用程序的任何其他版本旁边。
例如,如果您有两个版本的软件并且它们具有不同的“升级”代码,那么对于Windows而言,无论名称是什么,它们都是完全不同的软件。但是,如果“升级”代码相同,但“产品”代码不同,那么当您尝试安装第二个msi时,它会询问您是否要升级,此时它应该复制来自旧配置到新配置。如果两个值相同,并且版本号没有更改,则新配置将与旧配置位于同一位置,并且它不必执行任何操作。 MSDN Documentation
ClickOnce有点不同,因为它更多地基于ClickOnce版本#和URL路径,但我发现只要您继续“发布”到同一位置,新版本的应用程序将继续使用现有配置。 (link to how ClickOnce handles updates)
我也知道有一种方法可以在使用自定义安装脚本安装msi的过程中手动合并配置,但我不记得确切的步骤...(请参阅this链接了解如何使用web.config执行此操作
答案 2 :(得分:32)
user.config文件存储在
c:\Documents and Settings>\<username>\[Local Settings\]Application Data\<companyname>\<appdomainname>_<eid>_<hash>\<verison>
<c:\Documents and Settings>
是用户数据目录,可以是非漫游(上面的本地设置)或漫游
<username>
是用户名
<companyname>
是CompanyNameAttribute值(如果可用)。否则,请忽略此元素
<appdomainname>
是AppDomain.CurrentDomain.FriendlyName。这通常默认为.exe名称
<eid>
是URL,StrongName或Path,基于可用于哈希的证据
<hash>
是从CurrentDomain收集的证据的SHA1哈希值,按以下优先顺序排列:
1.强名字
2.网址:
如果这些都不可用,请使用.exe路径
<version>
是AssemblyInfo的AssemblyVersionAttribute设置
完整说明在http://msdn.microsoft.com/en-us/library/ms379611.aspx
答案 3 :(得分:4)
(我将此作为评论添加到@ Amr的答案,但我还没有足够的代表来做到这一点。)
info in the MSDN article非常明确,似乎仍然适用。然而,它没有提到SHA1散列是基于32编码写出的,而不是更典型的基数16。
我认为正在使用的算法是在ToBase32StringSuitableForDirName
中实现的,can be found here in the Microsoft Reference Source。