SymbolSource服务器问题

Question

我们正在为我们的开发团队设置一个本地SymbolSource服务器。我们跟着一篇写在SymbolSource服务器上的好文章。我们使用TeamCity来构建。对于每个构建，使用.symbols.nupkg命令将SymbolSource推送到本地SymbolSource，将nuget包推送到本地NuGet服务器。

我们正在经历的问题：

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

在Visual中设置符号服务器配置之后，我们尝试调试该项目。我们正在体验的是，Visual生成的用于加载符号的散列与在符号服务器上使用nuget push注册时生成的哈希完全不同，后者在404中结束。(请参阅附带的带有小提琴状态代码的文件。)如果我们在符号服务器上使用相同的哈希手工创建一个文件夹，我们就会得到期望的结果，即进入代码。

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

​

​

Answer 1

您得到的值不是散列(就像它们不是文件内容散列一样)，它们是GUID。每个DLL - PDB对在生成时都被分配一个GUID .每个DLL的 build 都有一个不同的 GUID，即使它们是从完全相同的源代码构建的！这意味着，从符号服务器获取PDB的唯一方法是使用完全相同的DLL。事实上，您得到了一个完全不同的GUID，这向我表明您没有使用相同的DLL。因此，在这种情况下，我可以想到的情况是：

• 您的符号nuget包有一个与普通nuget包不同的dll。如果同时生成包和二进制文件，这似乎不太可能，但是如果您多次构建包和二进制文件，则这是可能的。
• 您没有使用nuget包中的dll，该包的符号包已在您的符号服务器上注册。
• 您根本没有使用nuget包中的dll。

您的“修复”之所以有效，是因为Visual显然只使用GUID来创建符号搜索路径，而不会在PDB加载时检查它。换句话说，它假定(公平地)符号服务器将符号放置在正确的位置。

解决问题的最好方法是找出从哪里获得不同的DLL。可以使用垃圾箱实用程序来查找哪个DLL链接到哪个DLL。

dumpbin.exe /headers mypackage.dll

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