我们正在为我们的开发团队设置一个本地 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 文件有两个不同的哈希?
最佳答案
您获得的值不是散列(因为它们不是文件内容散列),它们是 GUIDs .每个 DLL - PDB 对在构建时都会被分配一个 GUID。每个构建 DLL 的一个 不同 GUID,即使它们是从完全相同的源代码构建的!这意味着从符号服务器获取 PDB 的唯一方法是使用完全相同的 DLL。您获得完全不同的 GUID 的事实向我表明您没有使用相同的 DLL。所以在这种情况下我可以想出的场景是:
您的“修复”工作的原因是因为 Visual Studio 显然只使用 GUID 来创建符号搜索路径,但在加载时不检查 PDB GUID。换句话说,它假设(相当)符号服务器将符号放在正确的位置。
解决问题的最佳方法是找出从何处获取不同的 DLL。您可以使用 dumpbin通过使用找出哪个 PDB 链接到哪个 DLL 的实用程序
dumpbin.exe /headers mypackage.dll
这应该会产生一个输出,其中包含 PDB 文件的路径和(!)链接 DLL 和 PDB 的 GUID。如果您将计算机上 DLL 的 GUID 和时间戳与符号服务器上的 DLL/PDB 中的 GUID 和时间戳进行比较,您应该能够找出问题出在哪里。
关于.net - SymbolSource 服务器问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/23096094/