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

【问题标题】：Can I control the location of .NET user settings to avoid losing settings on application upgrade?我可以控制 .NET 用户设置的位置以避免在应用程序升级时丢失设置吗？
【发布时间】：2010-10-11 21:34:19
【问题描述】：

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

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

我希望它与应用程序的版本无关

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

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

【问题讨论】：

虽然uzbones's 的回答提供了有关文件位置的信息，但我相信Ian's 在升级方面更正确。
@AnthonyMastrean 我个人认为任何重要的设置都不应该依赖于我的 Microsoft 提供的 ApplicationSettings 基础架构。 Muxa 应该只将设置存储在 %AppData%\[CompanyName]/[ProductName] 中，我们可以相信它会保留。
毫无疑问，我对内置应用程序和用户设置的持续体验非常糟糕。我推荐 appdata 或 programdata 中的 json 文件。
您还可以将设置存储在注册表中。请参阅stackoverflow.com/a/12127888/1273550 了解替代设置类的实现。

标签： .net-2.0 settings

【解决方案1】：

我想添加这个引用的文本作为将来我遇到此问题时的参考。假设您可以通过调用 Upgrade 来指示 ApplicationSettings 基础架构从以前的版本复制设置：

Properties.Settings.Value.Upgrade();

来自Client Settings FAQ 博文：(archive)

问：为什么 user.config 路径中有版本号？如果我部署新版本的应用程序，用户不会丢失之前版本保存的所有设置吗？

答：有几个原因 user.config 路径是版本敏感的。

(1) 支持并行部署不同版本的应用程序（你可以这样做例如，单击一次）。它是可能适用于不同版本的应用程序有不同的设置救了出来。

(2) 当您升级应用程序，设置类可以已被更改，可能不会与保存的内容兼容，这可能会导致问题。

但是，我们可以轻松地从以前的升级设置应用程序的版本最新的。只需调用 ApplicationSettingsBase.Upgrade() 和它将从以前的版本匹配类和商店的当前版本他们在当前版本的用户配置文件。你也有覆盖此行为的选项在您的设置类或你的提供者实现。

问：好的，但我怎么知道什么时候呼叫升级？

答：好问题。在 Clickonce 中，当您安装了新版本的应用程序，ApplicationSettingsBase 会自动检测到它为您升级设置设置已加载。在非 Clickonce 中情况下，没有自动升级 - 你必须自己打电话升级。这是确定何时调用升级：

有一个名为的布尔设置 CallUpgrade 并给它一个默认值真值。当您的应用启动时起来，你可以这样做：

if (Properties.Settings.Value.CallUpgrade)
{
   Properties.Settings.Value.Upgrade();
   Properties.Settings.Value.CallUpgrade = false;    
}

这将确保 Upgrade() 是仅第一次调用应用程序在新版本之后运行已部署。

我根本不相信它真的可以工作 - 微软不可能提供这种能力，但方法是一样的。

【讨论】：

这完全可行！我只使用了简单的if(CallUpgrade) { Upgrade(); } 语句。
@Ian Boyd：我喜欢这个想法，我对有一个潜在的解决方案感到非常兴奋，但是我对一件事感到困惑。我没有Properties.Settings.Value 我有Properties.Settings 部分，但我是否遗漏了某些内容或者是您特有的？
这个很好用，但是我提醒读者，配置的路径到但不包括版本号必须是相同的。即见@Amr的回答。例如如果应用程序的新版本从与以前版本不同的文件路径启动，则Upgrade 不起作用。
@RefractedPaladin 这是Properties.Settings.Default.Upgrade()
改成false后别忘了加上Properties.Settings.Default.Save(); :-)

【解决方案2】：

要回答第一个问题，从技术上讲，您可以将文件放在您想要的任何位置，但是您必须自己编写代码，因为文件的默认位置是您的两个示例中的第一个。 (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）

【讨论】：

升级代码不是应该保持不变的代码，而产品代码不是应该在版本之间更改的代码吗？ blogs.msdn.com/b/pusu/archive/2009/06/10/understanding-msi.aspx
噢！你是对的，不敢相信我把它弄反了（花了 2 年时间才赶上它）。这就像在我过去的某个时间点进行机器人签名:(
这是否意味着只有安装用户才能升级她的设置？

【解决方案3】：

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 或路径，基于可用于散列的证据。
<hash> 是从 CurrentDomain 收集的证据的 SHA1 散列，在以下优先顺序：
1. 强名
2. 网址：
如果这些都不可用，请使用 .exe 路径。
<version> 是 AssemblyInfo 的 AssemblyVersionAttribute 设置。

完整的描述在这里http://msdn.microsoft.com/en-us/library/ms379611.aspx

【讨论】：

【解决方案4】：

（我会将此作为评论添加到@Amr 的答案中，但我还没有足够的代表来做这件事。）

info in the MSDN article 非常明确，似乎仍然适用。但是它没有提到 SHA1 哈希是用 base 32 编码的，而不是更典型的 base 16。

我相信正在使用的算法是在ToBase32StringSuitableForDirName 中实现的，can be found here in the Microsoft Reference Source。

【讨论】：