4

我们正在为我们的开发团队设置本地 SymbolSource 服务器。我们关注了一篇写在 SymbolSource 服务器上的好文章。我们使用 TeamCity 进行构建。使用命令将每个构建.symbols.nupkg推送到本地 SymbolSource nuget push，并将 nuget 包推送到本地 NuGet 服务器。

我们遇到的问题：

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

在 Visual Studio 中设置符号服务器配置后，我们尝试调试项目。我们遇到的是，Visual Studio 生成的用于加载符号的哈希与nuget push在符号服务器上注册时生成的哈希完全不同，最终结果为 404。（请参阅带有提琴手状态代码的附件。）如果我们创建一个在符号服务器上手动使用相同的哈希文件夹，我们得到期望的结果，即步入代码。

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

生成了两个不同的 guid 提琴手输出

4

1 回答 1

2

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

  • 您的符号 nuget 包与您的普通 nuget 包具有不同的 dll。如果您同时生成两者，这似乎不太可能，但是如果您多次构建包和二进制文件，这是可能的。
  • 您没有使用已将其符号包注册到符号服务器的 nuget 包中的 dll
  • 您根本没有使用 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 和时间戳进行比较，您应该能够找出问题所在。

于 2014-04-15T23:38:56.133 回答