.net - SymbolSource 服务器问题

Question

我们正在为我们的开发团队设置一个本地 SymbolSource 服务器。我们关注了 a nice article written on SymbolSource server .我们使用 TeamCity 进行构建。对于每个构建 .symbols.nupkg使用 nuget push 推送到本地 SymbolSource命令和 nuget 包被推送到本地 NuGet 服务器。

我们遇到的问题:

对于 nuget 包 MyPackage.1.1.0，如果我们将其推送到符号服务器，它会创建哈希，这就是它如何关联每个版本文件夹以加载 .pdb文件和 .cs文件。 (这是我的理解。如果我错了，请纠正我)。

在 Visual Studio 中设置符号服务器配置后，我们尝试调试项目。我们遇到的是，Visual Studio 生成的用于加载符号的散列与使用 nuget push 注册时生成的散列完全不同。在以 404 结束的符号服务器上。(请参阅带有 fiddler 状态代码的附件。)如果我们在符号服务器上手动创建一个具有相同哈希值的文件夹，我们会得到所需的结果，即进入代码。

为什么相同版本的 dll/nuget 文件有两个不同的哈希？

Answer 1

您获得的值不是散列(因为它们不是文件内容散列)，它们是 GUIDs .每个 DLL - PDB 对在构建时都会被分配一个 GUID。每个构建 DLL 的一个 不同 GUID，即使它们是从完全相同的源代码构建的!这意味着从符号服务器获取 PDB 的唯一方法是使用完全相同的 DLL。您获得完全不同的 GUID 的事实向我表明您没有使用相同的 DLL。所以在这种情况下我可以想出的场景是:

您的符号 nuget 包具有与普通 nuget 包不同的 dll。如果您同时生成两者，这似乎不太可能，但是如果您多次构建包和二进制文件，这是可能的。

您没有使用 nuget 包中的 dll，该 nuget 包的符号包已在您的符号服务器中注册

您根本没有使用 nuget 包中的 dll

您的“修复”工作的原因是因为 Visual Studio 显然只使用 GUID 来创建符号搜索路径，但在加载时不检查 PDB GUID。换句话说，它假设(相当)符号服务器将符号放在正确的位置。

解决问题的最佳方法是找出从何处获取不同的 DLL。您可以使用 dumpbin通过使用找出哪个 PDB 链接到哪个 DLL 的实用程序

dumpbin.exe /headers mypackage.dll

这应该会产生一个输出，其中包含 PDB 文件的路径和(!)链接 DLL 和 PDB 的 GUID。如果您将计算机上 DLL 的 GUID 和时间戳与符号服务器上的 DLL/PDB 中的 GUID 和时间戳进行比较，您应该能够找出问题出在哪里。