我可以控制 .NET 用户设置的位置以避免在应用程序升级时丢失设置吗？
我正在尝试自定义 user.config 文件的位置。 目前它存储有哈希值和版本号，
%AppData%\[CompanyName]\[ExeName]_Url_[some_hash]\[Version]\
我希望它与应用程序的版本无关
%AppData%\[CompanyName]\[ProductName]\
这可以完成吗？如何完成？ 有何影响？升级后用户会丢失之前版本的设置吗？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我想添加这段引用的文字作为将来遇到此问题时的参考。 据说您可以通过调用 升级：
来自客户端设置常见问题解答博客文章：< em>(存档）
我不相信它真的可以工作——微软不可能提供这种能力，但方法是一样的。
I wanted to add this quoted text as a reference for when i have this problem in the future. Supposedly you can instruct the ApplicationSettings infrastructure to copy settings from a previous version by calling Upgrade:
From Client Settings FAQ blog post: (archive)
i don't believe for a second that it could actually work - there's no way Microsoft would provide this ability, but the method is there just the same.
要回答第一个问题，从技术上讲，您可以将文件放在您想要的任何位置，但是您必须自己编写代码，因为文件所在的默认位置是两个示例中的第一个。 （链接到如何自己动手）
至于第二个问题，这取决于你如何部署应用程序。 如果您通过 .msi 进行部署，则安装项目（msi 的构建基础）的属性中有两个哈希值：“升级代码”和“产品代码”。 这些决定了如何安装 msi，以及它是否升级、覆盖或安装在同一应用程序的任何其他版本旁边。
例如，如果您的软件有两个版本，并且它们具有不同的“升级”代码，那么对于 Windows，无论名称是什么，它们都是完全不同的软件。 但是，如果“升级”代码相同，但“产品”代码不同，那么当您尝试安装第二个 msi 时，它会询问您是否要升级，此时应该从旧配置到新配置。 如果两个值相同，并且版本号未更改，则新配置将位于与旧配置相同的位置，并且无需执行任何操作。 MSDN 文档
ClickOnce 有点不同，因为它更多地基于 ClickOnce 版本号和 URL 路径，但是我发现只要您继续“发布”到相同的版本location 新版本的应用程序将继续使用现有的配置。 （指向 ClickOnce 如何处理更新的链接）
我也知道有一种方法可以在使用自定义安装脚本安装 msi 期间手动合并配置，但我不记得具体的步骤...（请参阅此链接了解如何使用 web.config 进行此操作）
To answer the first question, you technically can put the file wherever you want, however you will have to code it yourself, as the default place the file goes to is the first of your two examples. (link to how to do it yourself)
As for the second question, it depends on how you deploy the application. If you deploy via a .msi, then there are two hashes in the properties of the setup project (that the msi is built from), the 'upgrade code' and the 'product code'. These determine how the msi can be installed, and if it upgrades, overwrites, or installs beside any other version of the same application.
For instance, if you have two versions of your software and they have different 'upgrade' codes, then to windows they are completely different pieces of software regardless of what the name is. However if the 'upgrade' code is the same, but the 'product' code is different then when you try to install the 2nd msi it will ask you if you want to upgrade, at which time it is supposed to copy the values from the old config to a new config. If both values are the same, and the version number didn't change then the new config will be in the same location as the old config, and it won't have to do anything. MSDN Documentation
ClickOnce is a little bit different, because its based more off of the ClickOnce version # and URL path, however I have found that as long as you continue to 'Publish' to the same location the new version of the application will continue to use the existing config. (link to how ClickOnce handles updates)
I also know there is a way to manually merge configs during the install of the msi using custom install scripts, but I don't remember the exact steps to do it... (see this link for how to do it with a web.config)
user.config 文件存储在
C:\Documents and Settings>\\[Local Settings\]Application Data\\__< hash>\ <C:\Documents and Settings> 是用户数据目录，可以是非漫游（上面的本地设置）或漫游。
1.强名
2.网址：
如果这些都不可用，请使用 .exe 路径。
完整说明位于此处 http://msdn.microsoft.com/en-us/库/ms379611.aspx
The user.config file is stored at
C:\Documents and Settings>\<username>\[Local Settings\]Application Data\<companyname>\<appdomainname>_<eid>_<hash>\<version><C:\Documents and Settings>is the user data directory, either non-roaming (Local Settings above) or roaming.<username>is the user name.<companyname>is the CompanyNameAttribute value, if available. Otherwise, ignore this element.<appdomainname>is the AppDomain.CurrentDomain.FriendlyName. This usually defaults to the .exe name.<eid>is the URL, StrongName, or Path, based on the evidence available to hash.<hash>is a SHA1 hash of evidence gathered from the CurrentDomain, in the following order of preference:1. StrongName
2. URL:
If neither of these is available, use the .exe path.
<version>is the AssemblyInfo's AssemblyVersionAttribute setting.Full description is here http://msdn.microsoft.com/en-us/library/ms379611.aspx
（我会将此作为评论添加到 @Amr 的答案，但我还没有足够的代表来执行此操作。）
MSDN 文章中的信息非常清楚，似乎仍然适用。 然而，它没有提到 SHA1 哈希值是以 32 进制编码写出的，而不是更典型的 16 进制。
我相信所使用的算法是在
ToBase32StringSuitableForDirName中实现的，其中 可以在 Microsoft 参考源中找到。(I'd add this as a comment to @Amr's answer, but I don't have enough rep to do that yet.)
The info in the MSDN article is very clear and appears to still apply. However it fails to mention that the SHA1 hash is written out base 32 encoded, rather than the more typical base 16.
I believe the algorithm being used is implemented in
ToBase32StringSuitableForDirName, which can be found here in the Microsoft Reference Source.