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

StackOverflow https://stackoverflow.com/questions/621265

  •  05-07-2019
  •  | 
  •  

题

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

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

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

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

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

有帮助吗？

解决方案

要回答第一个问题，从技术上讲，您可以将文件放在任何位置，但是您必须自己编写代码，因为文件的默认位置是您的两个示例中的第一个。 （链接到自己如何做）

至于第二个问题，这取决于您部署应用程序的方式。如果通过.msi进行部署，则安装项目的属性中有两个哈希值（构建msi），“升级代码”和“产品代码”。这些决定了msi的安装方式，以及它是否可以升级，覆盖或安装在同一应用程序的任何其他版本旁边。

例如，如果您有两个版本的软件并且它们具有不同的“升级”代码，那么对于Windows而言，无论名称是什么，它们都是完全不同的软件。但是，如果“升级”代码相同，但“产品”代码不同，那么当您尝试安装第二个msi时，它会询问您是否要升级，此时它应该复制来自旧配置到新配置。如果两个值相同，并且版本号没有更改，那么新配置将与旧配置位于同一位置，并且它不必执行任何操作。 MSDN文档

ClickOnce有点不同，因为它更多地基于ClickOnce版本＃和URL路径，但我发现只要您继续“发布”到同一位置，新版本的应用程序将继续使用现有配置。 （链接到ClickOnce如何处理更新 ）

我也知道有一种方法可以在使用自定义安装脚本安装msi时手动合并配置，但我不记得执行它的确切步骤...（参见这个链接，了解如何使用web.config进行操作）

其他提示

我希望将此引用的文字添加为我将来遇到此问题时的参考。据说，您可以通过调用升级：

Properties.Settings.Value.Upgrade();

来自客户端设置常见问题解答博文：（归档）

  

问：为什么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（）   只是第一次打电话   应用程序在新版本之后运行   已部署。

我不相信它能真正发挥作用 - 微软不可能提供这种能力，但方法也是如此。

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. StrongName
    2.网址：
如果这些都不可用，请使用.exe路径。
<version>是AssemblyInfo的AssemblyVersionAttribute设置。
点击 完整描述在这里 http://msdn.microsoft.com/en-us/library /ms379611.aspx

（我将此添加为对@ Amr的答案的评论，但我还没有足够的代表来做到这一点。）

MSDN文章中的信息非常清晰，似乎仍然适用。然而，它没有提到SHA1散列是基于32编码写出的，而不是更典型的基数16。

我相信正在使用的算法是在ToBase32StringSuitableForDirName中实现的，可以在Microsoft参考源中找到。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top