当我运行.net exe 时，创建了一个相应的文件夹C:\Users\UserName\AppData\Local\AppName
在此文件夹内，将创建另一个文件夹AppName_Url_ABCXYZ
在此文件夹中，将为.net exe0.2.28.0的程序集版本创建另一个文件夹
任何人都可以解释 Windows 如何决定创建第二级文件夹AppName_Url_ABCXYZ？
当我增加我的程序集版本并执行单个文件发布并运行结果 exe 时，我有一个问题，创建一个新的AppName_Url_ABCXYZ文件夹包含新的程序集版本文件夹。
这会导致问题，因为它会Properties.Settings.Default.Upgrade()的功能，因为要升级的设置不再位于预期的目录中
良好:
-AppData
-Local
-MyApp
-MyApp_Url_ABCXYZ
-0.2.13.0
-0.2.14.0
-0.2.15.0
坏:
-AppData
-Local
-MyApp
-MyApp_Url_ABC1
-0.2.13.0
-MyApp_Url_ABC2
-0.2.14.0
-MyApp_Url_ABC3
-0.2.15.0
更新：
@ Richard Deeming 提供的信息表明 appdata 文件夹的哈希部分是这样生成的：
var uri = "file:///" + fullExePath; //or 'assemblyName.CodeBase' if vshost (you can check the 'FriendlyName')
uri = uri.ToUpperInvariant();
var ms = new MemoryStream();
var bSer = new BinaryFormatter();
bSer.Serialize(ms, uri);
ms.Position = 0;
var sha1 = new SHA1CryptoServiceProvider();
var hash = sha1.ComputeHash(ms);
var hashstring = ToBase32StringSuitableForDirName(hash);
这是没有意义的，因为 exe 路径没有改变
这个问题不会发生与一个全新的 WPF.NET 6 应用程序和递增的汇编版本，所以它的东西具体到我的应用程序。
检查产生的 exe 在 Windows 资源管理器没有帮助，他们似乎是相同的。
更新：
我一直无法确定为什么在我的项目中会发生这种情况。我甚至不知道如何调试它。我从未对此行为进行任何有意的更改。
1
如果我的理解是正确的，则使用有问题的文件夹（C:\Users\UserName\AppData\Local\AppName\AppName_Url_ABCXYZ）存储user.config设置，请检查以下线程：
这里是来自 FAQ 的报价：https://learn.microsoft.com/en-us/archive/blogs/rprabhu/client-settings-faq
user.config文件的确切路径如下所示：
<Profile Directory>\<Company Name>\<App Name>_<Evidence Type>_<Evidence Hash>\<Version>\user.config
哪里
<Profile Directory>-是漫游配置文件目录或本地目录。默认情况下，设置存储在本地用户.config 文件中。要将设置存储在漫游用户.config 文件中，您需要使用设置为漫游的 SettingsManageabilityAttribute 标记设置。
<Company Name>-通常是由 AssemblyCompanyAttribute 指定的字符串（需要注意的是，字符串将根据需要进行转义和截断，如果未在程序集上指定，则我们有一个回退过程）。
<App Name>-通常是由 AssemblyProductAttribute 指定的字符串（与公司名称相同的警告）。
<Evidence Type>和<Evidence Hash>-从应用程序域证据派生的信息，以提供适当的应用程序域和程序集隔离。
<Version>-通常是在 AssemblyVersionAttribute 中指定的版本。这是隔离并排部署的应用程序的不同版本所必需的。
文件名总是user.config。
如果你想以编程方式到达路径，你可以使用配置管理 API（你需要添加一个引用 System.Configuration.dll）。
路径构建算法必须满足安全性，隔离性和鲁棒性方面的某些严格要求。虽然我们试图通过使用友好的应用程序提供的字符串使路径尽可能容易被发现，但不可能在不遇到与其他应用程序冲突，欺骗等问题的情况下保持路径完全简单。
LocalFileSettingsProvider 不提供更改存储设置的文件的方法。请注意,提供者本身不会首先确定配置文件的位置-它是配置系统。如果由于某种原因需要将设置存储在不同的位置,建议的方法是编写自己的 SettingsProvider。
看起来微软故意没有提供配置配置文件的路径以避免冲突的方法。上面提到的 SO 线程似乎提供了一些关于实现自定义SettingsProvider的说明。
在您的情况下，更新版本后<Evidence Hash>部分有所不同，这里还有一个线程描述可能的原因：https://social.msdn.microsoft.com/Forums/vstudio/en-US/d87a0add-00ba-4074-8ef3-cf085e1122eb/userscope-settings-path-changed-after-upgrade?forum=netfxbcl
证据哈希值已更改，因为该值受两个因素影响，有关详细信息，请check this link，
1.StrongName
2.URL
如果这两个都不可用，请使用.exe 路径。
<Evidence Type>可以是 URL,StrongName 或 Path,基于可用于哈希的证据。在有问题的路径中,我可以看到它设置为 Url。正如我在“Programming.NET Security”一书中发现的那样,Url 证据表示从中加载程序集的 URL。如果它是从磁盘加载的,则它将是文件:/ / URL。虽然没有用示例检查它。
可能是 URL 更改或 EXE 路径更改影响了哈希值。
此外，有必要检查程序集强名称是否已更改。
强名称由程序集的标识 (其简单文本名称、版本号和区域性信息 (如果提供)) 以及公钥和数字签名组成。它是使用相应的私钥从程序集文件生成的。(程序集文件包含程序集清单，其中包含组成程序集的所有文件的名称和哈希。)https://learn.microsoft.com/en-us/dotnet/standard/assembly/create-use-strong-named
0
为了演示，让我们创建一个简单的控制台应用程序：
并添加一个链接到它：
<PackageReference Include="System.Configuration.ConfigurationManager" Version="6.0.0" />
我们还将添加 Settings.settings 项目属性文件。因此，我们在以下配置中获得一个项目：
在调试模式下编译并运行 ConsoleApp1.exe 的结果后，我们沿着路径 C：\ Users\ \ AppData\ Local\ ConsoleApp1 获得以下图片：
在此文件夹中，将有一个带有程序版本号的文件夹：
编译发布版本并运行 ConsoleApp1.exe 的结果时，我们沿着路径 C：\ Users\ \ AppData\ Local\ ConsoleApp1 获得以下图片：
在这个新文件夹中，还将有一个带有程序版本号的文件夹：
应该注意的是，程序的调试和发布版本会创建不同的文件夹。
更改项目版本时，新版本将分别显示在 debug 和 release 文件夹中：
调试和发布程序是同一项目的不同编译“版本”，并且创建不同的 URL 来分隔它们。
Download the entire project package here – ConsoleApp1.zip本站系公益性非盈利分享网址，本文来自用户投稿，不代表码文网立场，如若转载，请注明出处
评论列表（27条）