我可以控制.NET用户设置的位置,以避免丢失应用程序升级的设置吗?

时间:2009-03-07 03:50:33

标签: .net-2.0 settings

我正在尝试自定义user.config文件的位置。目前,它存储了哈希和版本号

%AppData%\[CompanyName]\[ExeName]_Url_[some_hash]\[Version]\

我希望它对应用程序的版本不可知

%AppData%\[CompanyName]\[ProductName]\

可以这样做吗?有什么影响?升级后用户是否会丢失以前版本的设置?

4 个答案:

答案 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